From nbenalla at openjdk.org  Tue Jun  4 00:41:07 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Jun 2024 00:41:07 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <g8LobAe5ZNYKbM6gXSF_nqEwM3PvH7sggS2mVOjOqCQ=.1713b92b-6539-41ad-9d6a-d3a4fff08d27@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
>> 
>> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

Here is a snippet from the report of the checker with the relevant bits for this PR

STDERR:
method: void java.io.PrintStream.write(byte[]): `@since` version is 14 but the element exists before JDK 10
method: java.lang.invoke.MethodHandle java.lang.invoke.MethodHandles.tableSwitch(java.lang.invoke.MethodHandle,java.lang.invoke.MethodHandle[]): `@since` version is 9 instead of 17
method: void java.lang.reflect.MalformedParameterizedTypeException.<init>(java.lang.String): `@since` version is 9 instead of 10
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.slice(): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.slice(int,int): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.duplicate(): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.compact(): `@since` version is 9 instead of 17
method: void java.util.Properties.<init>(int): `@since` version is 9 instead of 10
method: float java.util.concurrent.ThreadLocalRandom.nextFloat(float): `@since` version is 9 instead of 17
method: float java.util.concurrent.ThreadLocalRandom.nextFloat(float,float): `@since` version is 9 instead of 17
method: void java.util.zip.Deflater.setDictionary(java.nio.ByteBuffer): `@since` version is 9 instead of 11




Here is the full report

STDERR:
method: void java.io.PrintStream.write(byte[]): `@since` version is 14 but the element exists before JDK 10
method: byte[] java.io.FileInputStream.readNBytes(int): `@since` version is 9 instead of 11
method: java.lang.classfile.Signature.ClassTypeSig java.lang.classfile.ClassSignature.superclassSignature(): `@since` version is 22 instead of 23
method: java.lang.classfile.constantpool.PoolEntry java.lang.classfile.ClassReader.readEntryOrNull(int,java.lang.Class): `@since` version is 24 instead of 23
method: java.lang.classfile.constantpool.PoolEntry java.lang.classfile.constantpool.ConstantPool.entryByIndex(int,java.lang.Class): `@since` version is 24 instead of 23
method: java.lang.Class java.lang.constant.ClassDesc.resolveConstantDesc(java.lang.invoke.MethodHandles.Lookup): `@since` version is 12 instead of 21
method: java.lang.invoke.MethodType java.lang.constant.MethodTypeDesc.resolveConstantDesc(java.lang.invoke.MethodHandles.Lookup): `@since` version is 12 instead of 21
method: java.lang.invoke.MethodHandle java.lang.constant.MethodHandleDesc.resolveConstantDesc(java.lang.invoke.MethodHandles.Lookup): `@since` version is 12 instead of 21
method: long java.lang.foreign.MemorySegment.maxByteAlignment(): `@since` version is 22 instead of 23
method: java.lang.invoke.MethodHandle java.lang.invoke.MethodHandles.tableSwitch(java.lang.invoke.MethodHandle,java.lang.invoke.MethodHandle[]): `@since` version is 9 instead of 17
method: java.lang.Object java.lang.ref.Reference.clone(): `@since` version is 11 but the element exists before JDK 10
method: void java.lang.reflect.MalformedParameterizedTypeException.<init>(java.lang.String): `@since` version is 9 instead of 10
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.slice(): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.slice(int,int): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.duplicate(): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.compact(): `@since` version is 9 instead of 17
method: boolean java.text.ChoiceFormat.isStrict(): `@since` version is 9 instead of 23
method: void java.text.ChoiceFormat.setStrict(boolean): `@since` version is 9 instead of 23
method: void java.util.Properties.<init>(int): `@since` version is 9 instead of 10
method: java.lang.Object java.util.concurrent.FutureTask.resultNow(): `@since` version is 9 instead of 19
method: java.lang.Throwable java.util.concurrent.FutureTask.exceptionNow(): `@since` version is 9 instead of 19
method: java.util.concurrent.Future.State java.util.concurrent.FutureTask.state(): `@since` version is 9 instead of 19
method: float java.util.concurrent.ThreadLocalRandom.nextFloat(float): `@since` version is 9 instead of 17
method: float java.util.concurrent.ThreadLocalRandom.nextFloat(float,float): `@since` version is 9 instead of 17
method: java.util.concurrent.Future.State java.util.concurrent.ForkJoinTask.state(): `@since` version is 9 instead of 19
method: java.lang.Object java.util.concurrent.ForkJoinTask.resultNow(): `@since` version is 9 instead of 19
method: java.lang.Throwable java.util.concurrent.ForkJoinTask.exceptionNow(): `@since` version is 9 instead of 19
method: java.util.concurrent.Delayed java.util.concurrent.DelayQueue.remove(): `@since` version is 9 instead of 21
method: java.lang.Object java.util.concurrent.CompletableFuture.resultNow(): `@since` version is 9 instead of 19
method: java.lang.Throwable java.util.concurrent.CompletableFuture.exceptionNow(): `@since` version is 9 instead of 19
method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyAsync(java.util.function.Function): `@since` version is 9 instead of 12
method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyAsync(java.util.function.Function,java.util.concurrent.Executor): `@since` version is 9 instead of 12
method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyCompose(java.util.function.Function): `@since` version is 9 instead of 12
method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyComposeAsync(java.util.function.Function): `@since` version is 9 instead of 12
method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyComposeAsync(java.util.function.Function,java.util.concurrent.Executor): `@since` version is 9 instead of 12
method: java.util.concurrent.Future.State java.util.concurrent.CompletableFuture.state(): `@since` version is 9 instead of 19
method: void java.util.zip.Deflater.setDictionary(java.nio.ByteBuffer): `@since` version is 9 instead of 11
java.lang.Exception: The `@since` checker found 37 problems
        at SinceChecker.checkModule(SinceChecker.java:262)
        at SinceChecker.main(SinceChecker.java:123)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.Exception
JavaTest Message: shutting down test


TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: The `@since` checker found 37 problems
--------------------------------------------------

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

PR Comment: https://git.openjdk.org/jdk/pull/18055#issuecomment-2146354662

From jpai at openjdk.org  Tue Jun  4 11:38:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 11:38:09 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <uWRhKu369gf7BDLKcCkB0vd5ptaNcbHiMvXFIRp5QGU=.8f31d58d-d217-4dfe-8c2c-4ce297d74a76@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
>> 
>> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/io/PrintStream.java line 683:

> 681:      * @see #write(byte[],int,int)
> 682:      *
> 683:      * @since 14

The `@since 14` was added here as part of https://bugs.openjdk.org/browse/JDK-8187898. The CSR explains what the changes were https://bugs.openjdk.org/browse/JDK-8230625. As noted in that CSR's specification (and attached images), the change for this method in that issue ended up being just API clarification (through a `@apiNote`) and no other change to this specific method. It continued to have the same signature including the throws clause that was previously available on this class through the super `FilterOutputStream#write(byte[])` method.

So removing this `@since 14` looks correct to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625840895

From jpai at openjdk.org  Tue Jun  4 11:41:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 11:41:07 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <9cNhL1WSyM-7ciSlWChw51xUvYUQYf8-mKxII-yT9Z4=.262297ee-ee41-4112-bcec-d6c706559d68@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
>> 
>> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7925:

> 7923:      * @since 17
> 7924:      */
> 7925:     public static MethodHandle tableSwitch(MethodHandle fallback, MethodHandle... targets) {

This method was introduced in Java 17 through https://bugs.openjdk.org/browse/JDK-8263087. So this addition of `@since 17` looks fine to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625845162

From jpai at openjdk.org  Tue Jun  4 11:44:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 11:44:05 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <aZVdWWOpBrlzcEAKpfAMaQWxi6Ygia0qvJtrzb2-DOM=.18637220-5c17-477b-90a8-868d8ee32a98@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
>> 
>> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/lang/reflect/MalformedParameterizedTypeException.java line 56:

> 54:      * @since 10
> 55:      */
> 56:     public MalformedParameterizedTypeException(String message) {

Both this and the explicit no-arg constructor were introduced in this class through https://bugs.openjdk.org/browse/JDK-8183175 in Java 10. Since an (implicit) no-arg constructor was always available even before that change, it makes sense to add a `@since 10` to only this explicit constructor. This change looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625848542

From jpai at openjdk.org  Tue Jun  4 11:53:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 11:53:09 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <4iicrOFX4yXDID9AdiLV73BBhTU8GuFT5z3mq1g9Zn4=.7d507deb-35b4-40bc-8d47-dc8165b22730@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
>> 
>> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/nio/MappedByteBuffer.java line 404:

> 402:      */
> 403:     @Override
> 404:     public abstract MappedByteBuffer slice();

This and the other 3 methods on which this `@since 17` is being added here were introduced in Java 17, through https://bugs.openjdk.org/browse/JDK-4833719. Before that change, these methods would have been available on this `MappedByteBuffer` through the super `ByteBuffer` class and those methods have been specified to return a `ByteBuffer`. After that change in JDK-4833719, these methods now return a `MappedByteBuffer` which is an observable change. So adding `@since 17` to these methods looks correct to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625858949

From jpai at openjdk.org  Tue Jun  4 11:56:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 11:56:32 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <X8xDmi3GecEzZZOLCQ5rhqfUCj1JUP5oM6DeFZ8ioA0=.92ea7709-8eb0-4d3b-998a-3a88df933034@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
>> 
>> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/util/Properties.java line 190:

> 188:      * @since 10
> 189:      */
> 190:     public Properties(int initialCapacity) {

This constructor was introduced in Java 10 through https://bugs.openjdk.org/browse/JDK-8189319, so adding `@since 10` here looks correct to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625864049

From jpai at openjdk.org  Tue Jun  4 12:02:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 12:02:10 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <SbEk9j4jgaUfABUNVroMZxdupxj5oVCpZmmHLFsrUY8=.eb20204c-6363-49cd-ad21-77a3702d0649@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
>> 
>> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 513:

> 511:      */
> 512:     @Override
> 513:     public float nextFloat(float bound) {

These 2 `nextFloat(...)` methods which take parameters were introduced in Java 17 https://bugs.openjdk.org/browse/JDK-8248862, whereas the no-arg `nextFloat()` method existed prior to that. So adding `@since 17` to these 2 methods looks correct to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625871382

From jpai at openjdk.org  Tue Jun  4 12:09:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 12:09:13 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <3BU-FyIAlIKRp6fuWFZ1RLtiNk4Jqn1PzvpXBnUH8GI=.2b2a55d1-6db9-4e15-9411-c0b2c36d8552@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
>> 
>> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

These changes look good to me. Thank you Nizar for the work on the `@since` checker and these PRs in individual areas.

src/java.base/share/classes/java/util/zip/Deflater.java line 342:

> 340:      * @since 11
> 341:      */
> 342:     public void setDictionary(ByteBuffer dictionary) {

This method was introduced in Java 11 through https://bugs.openjdk.org/browse/JDK-6341887. It appears to be an oversight that a `@since 11` wasn't added to this method in that change, because other new methods introduced in that change did come with a `@since 11`. So this addition of `@since 11` now looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18055#pullrequestreview-2096192264
PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625879138

From nbenalla at openjdk.org  Tue Jun  4 16:17:54 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Jun 2024 16:17:54 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <9rwcxCtDSvNErRJA2krVv4LtregWT6UJflZ51MEpbBk=.e3b907f8-6734-4e14-8aef-5ec61d94cad7@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
>> 
>> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

Thanks for the thorough review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18055#issuecomment-2147542776

From nbenalla at openjdk.org  Tue Jun  4 16:54:07 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Jun 2024 16:54:07 GMT
Subject: Integrated: 8326951: since-checker - missing @ since tags
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <6_AxWxwLvM8is87Q-BRTBSqIpBIbxsin3XUcCMHW-Ng=.fe4ee43d-c805-4fc3-acf5-0a8a40b73e35@github.com>

On Thu, 29 Feb 2024 09:45:35 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
> 
> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
> 
> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
> 
> This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

This pull request has now been integrated.

Changeset: e0bab786
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e0bab786402d70e9a74d1816c029c772ea01f697
Stats:     24 lines in 7 files changed: 19 ins; 2 del; 3 mod

8326951: since-checker - missing @ since tags

Reviewed-by: jpai

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

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

From bpb at openjdk.org  Tue Jun  4 17:57:00 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Jun 2024 17:57:00 GMT
Subject: RFR: 8327650: Test
 java/nio/channels/DatagramChannel/StressNativeSignal.java timed out [v4]
In-Reply-To: <6z-US4fPo0TIN8WBSKbePi8q_6Iutrzbn5TNjSEwmg8=.66297c2d-5d22-4024-9f19-1e4eaceb8a6b@github.com>
References: <KGUIVS4pBQS-F72uy3s8wV9_liNzSCjQ-eKc5FbhnWw=.9c2cedfe-46fc-4035-95b9-776a102e38fd@github.com>
 <6z-US4fPo0TIN8WBSKbePi8q_6Iutrzbn5TNjSEwmg8=.66297c2d-5d22-4024-9f19-1e4eaceb8a6b@github.com>
Message-ID: <G5UP9wdFrPNRL6654DIQVB-jrlKBqIByPRTUnEKLAXA=.dbdafe97-01fc-4bd3-8471-cc0e59301bdb@github.com>

On Tue, 28 May 2024 11:15:35 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> JDK-8327650 Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out 
>> 
>> Please oblige and review the following test only fix to alleviate a race condition within the test.
>> 
>> A race condition exists, in the test  StressNativeSignal, due to the setting of a condition variable, shouldTerminate, in the main thread?s invocation of UDPThread::terminate and the setting of shouldTerminate in the main run method of UDPThread.  A similar scenario exists for the ServerSocketThread.  The variable shouldTerminate is a member variable, and is by default set to false, so the setting to false in the run methods is not required. Removing shouldTerminate = false; statement mitigates the race condition.
>> 
>> Additionally, a number of other minor changes have been added to the test:
>> * it is desired to test the asynchronous close of the DatagramChannel::receive method which may trigger the NativeThread::signal issue, thus the while loop has been changed to a do { } while(); loop to invoke the DC receive method.
>> 
>> * The Thread::sleep has been replaced with a CountDownLatch to make the test slightly more deterministic.
>> 
>> It is noted in passing the ServerSocket::run method contains a redundant while loop for reading from an established connection stream, which is never created. This code is never reached as there is no peer to connect to the ServerSocket and the test is on the ServerSocket::accept method.
>> 
>> Another issue of note is that the test is using a hardcoded IANA assigned port 1122 (availant-mgr). But, this has not been altered. The ServerSocket test scenario could use an ephemeral port i.e. new ServerSocket(0);
>
> Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8327650: Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out ? updated catch block to be consistent with idiom used in test

Approved given the follow up issue [JDK-8333526](https://bugs.openjdk.org/browse/JDK-8333526).

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19312#pullrequestreview-2097064178

From msheppar at openjdk.org  Tue Jun  4 23:37:06 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 4 Jun 2024 23:37:06 GMT
Subject: RFR: 8327650: Test
 java/nio/channels/DatagramChannel/StressNativeSignal.java timed out [v5]
In-Reply-To: <KGUIVS4pBQS-F72uy3s8wV9_liNzSCjQ-eKc5FbhnWw=.9c2cedfe-46fc-4035-95b9-776a102e38fd@github.com>
References: <KGUIVS4pBQS-F72uy3s8wV9_liNzSCjQ-eKc5FbhnWw=.9c2cedfe-46fc-4035-95b9-776a102e38fd@github.com>
Message-ID: <M5BDj3tMEuO_9VAYWQdguFHG8J_J3TceaJCZDrNUq9U=.ec12a565-6bbf-4a8b-bee4-cbe8c9592261@github.com>

> JDK-8327650 Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out 
> 
> Please oblige and review the following test only fix to alleviate a race condition within the test.
> 
> A race condition exists, in the test  StressNativeSignal, due to the setting of a condition variable, shouldTerminate, in the main thread?s invocation of UDPThread::terminate and the setting of shouldTerminate in the main run method of UDPThread.  A similar scenario exists for the ServerSocketThread.  The variable shouldTerminate is a member variable, and is by default set to false, so the setting to false in the run methods is not required. Removing shouldTerminate = false; statement mitigates the race condition.
> 
> Additionally, a number of other minor changes have been added to the test:
> * it is desired to test the asynchronous close of the DatagramChannel::receive method which may trigger the NativeThread::signal issue, thus the while loop has been changed to a do { } while(); loop to invoke the DC receive method.
> 
> * The Thread::sleep has been replaced with a CountDownLatch to make the test slightly more deterministic.
> 
> It is noted in passing the ServerSocket::run method contains a redundant while loop for reading from an established connection stream, which is never created. This code is never reached as there is no peer to connect to the ServerSocket and the test is on the ServerSocket::accept method.
> 
> Another issue of note is that the test is using a hardcoded IANA assigned port 1122 (availant-mgr). But, this has not been altered. The ServerSocket test scenario could use an ephemeral port i.e. new ServerSocket(0);

Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8327650 Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out ? updates from review feedback: test member variables udpThread and serverSocketThread have been made final, with initialisation from two init methods. Unused read loop in ServerSocketThread run method removed. In the event of an unforeseen return from the accept call, the socket is closed and a RuntimeException is thrown.
  Additionally, an auxiliary JBS item, JDK-8333526 has been opened to undertake the suggested restructuring of the test to ?fail fast? in the event of an impactful Exception being thrown during any stage of the test execution

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19312/files
  - new: https://git.openjdk.org/jdk/pull/19312/files/8e23220e..5faee215

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

  Stats: 37 lines in 1 file changed: 22 ins; 7 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19312.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19312/head:pull/19312

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

From msheppar at openjdk.org  Tue Jun  4 23:46:08 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 4 Jun 2024 23:46:08 GMT
Subject: RFR: 8327650: Test
 java/nio/channels/DatagramChannel/StressNativeSignal.java timed out [v6]
In-Reply-To: <KGUIVS4pBQS-F72uy3s8wV9_liNzSCjQ-eKc5FbhnWw=.9c2cedfe-46fc-4035-95b9-776a102e38fd@github.com>
References: <KGUIVS4pBQS-F72uy3s8wV9_liNzSCjQ-eKc5FbhnWw=.9c2cedfe-46fc-4035-95b9-776a102e38fd@github.com>
Message-ID: <Y9I43Wql4KkamlwUv9MkatkIK4UjcAmac1FBVeB23oo=.280faa5f-ca81-489a-95e7-a522d8fb6e11@github.com>

> JDK-8327650 Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out 
> 
> Please oblige and review the following test only fix to alleviate a race condition within the test.
> 
> A race condition exists, in the test  StressNativeSignal, due to the setting of a condition variable, shouldTerminate, in the main thread?s invocation of UDPThread::terminate and the setting of shouldTerminate in the main run method of UDPThread.  A similar scenario exists for the ServerSocketThread.  The variable shouldTerminate is a member variable, and is by default set to false, so the setting to false in the run methods is not required. Removing shouldTerminate = false; statement mitigates the race condition.
> 
> Additionally, a number of other minor changes have been added to the test:
> * it is desired to test the asynchronous close of the DatagramChannel::receive method which may trigger the NativeThread::signal issue, thus the while loop has been changed to a do { } while(); loop to invoke the DC receive method.
> 
> * The Thread::sleep has been replaced with a CountDownLatch to make the test slightly more deterministic.
> 
> It is noted in passing the ServerSocket::run method contains a redundant while loop for reading from an established connection stream, which is never created. This code is never reached as there is no peer to connect to the ServerSocket and the test is on the ServerSocket::accept method.
> 
> Another issue of note is that the test is using a hardcoded IANA assigned port 1122 (availant-mgr). But, this has not been altered. The ServerSocket test scenario could use an ephemeral port i.e. new ServerSocket(0);

Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8327650 Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out ? remove trailing white spaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19312/files
  - new: https://git.openjdk.org/jdk/pull/19312/files/5faee215..06160ff2

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

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

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

From bpb at openjdk.org  Wed Jun  5 00:38:00 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Jun 2024 00:38:00 GMT
Subject: RFR: 8327650: Test
 java/nio/channels/DatagramChannel/StressNativeSignal.java timed out [v6]
In-Reply-To: <Y9I43Wql4KkamlwUv9MkatkIK4UjcAmac1FBVeB23oo=.280faa5f-ca81-489a-95e7-a522d8fb6e11@github.com>
References: <KGUIVS4pBQS-F72uy3s8wV9_liNzSCjQ-eKc5FbhnWw=.9c2cedfe-46fc-4035-95b9-776a102e38fd@github.com>
 <Y9I43Wql4KkamlwUv9MkatkIK4UjcAmac1FBVeB23oo=.280faa5f-ca81-489a-95e7-a522d8fb6e11@github.com>
Message-ID: <UkL8qBl3V1KEhcFM9UCEU_R2DGvJiZrRCK-hQBvcK2g=.5cc66e67-a064-4eb8-bad3-dc900bc5fb95@github.com>

On Tue, 4 Jun 2024 23:46:08 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> JDK-8327650 Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out 
>> 
>> Please oblige and review the following test only fix to alleviate a race condition within the test.
>> 
>> A race condition exists, in the test  StressNativeSignal, due to the setting of a condition variable, shouldTerminate, in the main thread?s invocation of UDPThread::terminate and the setting of shouldTerminate in the main run method of UDPThread.  A similar scenario exists for the ServerSocketThread.  The variable shouldTerminate is a member variable, and is by default set to false, so the setting to false in the run methods is not required. Removing shouldTerminate = false; statement mitigates the race condition.
>> 
>> Additionally, a number of other minor changes have been added to the test:
>> * it is desired to test the asynchronous close of the DatagramChannel::receive method which may trigger the NativeThread::signal issue, thus the while loop has been changed to a do { } while(); loop to invoke the DC receive method.
>> 
>> * The Thread::sleep has been replaced with a CountDownLatch to make the test slightly more deterministic.
>> 
>> It is noted in passing the ServerSocket::run method contains a redundant while loop for reading from an established connection stream, which is never created. This code is never reached as there is no peer to connect to the ServerSocket and the test is on the ServerSocket::accept method.
>> 
>> Another issue of note is that the test is using a hardcoded IANA assigned port 1122 (availant-mgr). But, this has not been altered. The ServerSocket test scenario could use an ephemeral port i.e. new ServerSocket(0);
>
> Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8327650 Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out ? remove trailing white spaces

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19312#pullrequestreview-2097626793

From msheppar at openjdk.org  Wed Jun  5 15:51:01 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 5 Jun 2024 15:51:01 GMT
Subject: Integrated: 8327650: Test
 java/nio/channels/DatagramChannel/StressNativeSignal.java timed out
In-Reply-To: <KGUIVS4pBQS-F72uy3s8wV9_liNzSCjQ-eKc5FbhnWw=.9c2cedfe-46fc-4035-95b9-776a102e38fd@github.com>
References: <KGUIVS4pBQS-F72uy3s8wV9_liNzSCjQ-eKc5FbhnWw=.9c2cedfe-46fc-4035-95b9-776a102e38fd@github.com>
Message-ID: <J6xQJIvKAWygYpGx98whS2KkejEpU6o6LgNG__-rpB8=.345072de-f624-4588-a472-b7777266509c@github.com>

On Mon, 20 May 2024 14:32:10 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> JDK-8327650 Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out 
> 
> Please oblige and review the following test only fix to alleviate a race condition within the test.
> 
> A race condition exists, in the test  StressNativeSignal, due to the setting of a condition variable, shouldTerminate, in the main thread?s invocation of UDPThread::terminate and the setting of shouldTerminate in the main run method of UDPThread.  A similar scenario exists for the ServerSocketThread.  The variable shouldTerminate is a member variable, and is by default set to false, so the setting to false in the run methods is not required. Removing shouldTerminate = false; statement mitigates the race condition.
> 
> Additionally, a number of other minor changes have been added to the test:
> * it is desired to test the asynchronous close of the DatagramChannel::receive method which may trigger the NativeThread::signal issue, thus the while loop has been changed to a do { } while(); loop to invoke the DC receive method.
> 
> * The Thread::sleep has been replaced with a CountDownLatch to make the test slightly more deterministic.
> 
> It is noted in passing the ServerSocket::run method contains a redundant while loop for reading from an established connection stream, which is never created. This code is never reached as there is no peer to connect to the ServerSocket and the test is on the ServerSocket::accept method.
> 
> Another issue of note is that the test is using a hardcoded IANA assigned port 1122 (availant-mgr). But, this has not been altered. The ServerSocket test scenario could use an ephemeral port i.e. new ServerSocket(0);

This pull request has now been integrated.

Changeset: 7acfba28
Author:    Mark Sheppard <msheppar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7acfba288ff4d1f43cc36506b2bd2d32107b00c2
Stats:     110 lines in 1 file changed: 74 ins; 10 del; 26 mod

8327650: Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out

Reviewed-by: bpb

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

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

From cleber.muramoto at gmail.com  Fri Jun  7 17:00:57 2024
From: cleber.muramoto at gmail.com (Cleber Muramoto)
Date: Fri, 7 Jun 2024 14:00:57 -0300
Subject: Behavior of DatagramChannel vs ByteBuffers bound to MemorySessions
Message-ID: <CAECsnDR8L-1Wq7HjZVH77x4NvY+yRtRVwpbvV98Kww=m+rCJFA@mail.gmail.com>

Hello, I'd like to understand why a disconnected DatagramChannel does not
support direct buffers derived from MemorySegments created from shared
Arenas.

The connected code path uses IOUtil, which obtains the address via
JavaNioAccess and the disconnected one obtains the address
via ((sun.nio.ch.DirectBuffer)bb).address(), which undergoes MemorySession
validation semantics.

Example:

----
  var buffer =
Arena.ofShared().allocate(1024).asByteBuffer().putInt(42).flip();

  var dc = DatagramChannel.open();
  dc.bind(new InetSocketAddress(10000));
  dc.join(InetAddress.getByName("225.0.0.0"),
NetworkInterface.getByInetAddress(InetAddress.getLoopbackAddress()));

  // works
  dc.connect(new InetSocketAddress("225.0.0.0", 1024));
  dc.write(buffer);
  dc.disconnect();

  // UnsupportedOperationException
  dc.send(buffer.rewind(), new InetSocketAddress("225.0.0.0", 1024));
----

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240607/9272f2a5/attachment.htm>

From bpb at openjdk.org  Fri Jun  7 20:11:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Jun 2024 20:11:19 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v5]
In-Reply-To: <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
 <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
Message-ID: <d_vksHHt_rZYQwYyCAZ_5SXBjWRu-JMLKoUzzf2h0iM=.7492f972-9ff9-4142-becc-5c376110f956@github.com>

On Fri, 1 Mar 2024 21:48:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - 8315273: Re-remove ToRealPath test
>  - Merge
>  - 8315273: Revert ProblemList
>  - Merge
>  - Merge
>  - 8315273: Add bug ID to test
>  - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2155478508

From bpb at openjdk.org  Fri Jun  7 20:37:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Jun 2024 20:37:56 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v9]
In-Reply-To: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <0EGVPkz4pGwAiB2QNJyS3blAE9EyrZK5Di6bT0Ia53Y=.769b8f47-d61a-4902-8f78-72736d3b1cc6@github.com>

> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.

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

 - 8298318: Update @since tags
 - Merge
 - 8298318: Add parameter checks for withExtension
 - 8298318: Revise handling of leading periods
 - 8298318: corretions to commit 030a250aaf4c309d515507527932b233f210501e
 - 8298318: Address reviewer comments
 - 8298318: Remove vestigial trim() call and commented out methods
 - 8298318: Refine specification of extension; replace addExtension/removeExtension with withExtension/withoutExtension; update test
 - Merge
 - 8298318: Correct type in path.getExtension spec
 - ... and 2 more: https://git.openjdk.org/jdk/compare/348fa9b5...b27cf346

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16226/files
  - new: https://git.openjdk.org/jdk/pull/16226/files/8abc295f..b27cf346

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

  Stats: 693830 lines in 8322 files changed: 174385 ins; 165771 del; 353674 mod
  Patch: https://git.openjdk.org/jdk/pull/16226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16226/head:pull/16226

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

From Alan.Bateman at oracle.com  Sat Jun  8 08:21:53 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 8 Jun 2024 09:21:53 +0100
Subject: Behavior of DatagramChannel vs ByteBuffers bound to MemorySessions
In-Reply-To: <CAECsnDR8L-1Wq7HjZVH77x4NvY+yRtRVwpbvV98Kww=m+rCJFA@mail.gmail.com>
References: <CAECsnDR8L-1Wq7HjZVH77x4NvY+yRtRVwpbvV98Kww=m+rCJFA@mail.gmail.com>
Message-ID: <697068fb-794b-407e-8691-e86ad1db434f@oracle.com>

On 07/06/2024 18:00, Cleber Muramoto wrote:
> Hello, I'd like to understand why a disconnected DatagramChannel does 
> not support direct buffers derived from MemorySegments created from 
> shared Arenas.
>
>
A shared Arena can be closed at any time. There are safety guarantees 
that go along with that are problematic when doing I/O with byte buffers 
that are backed by a memory segment allocated. For APIs that do 
synchronous I/O then it may be possible to remove this restriction at 
some point. For APIs that do asynchronous I/O (as in initiate an I/O op 
on one thread, complete on another) then it is a harder problem.

-Alan



From cleber.muramoto at gmail.com  Sat Jun  8 15:55:12 2024
From: cleber.muramoto at gmail.com (Cleber Muramoto)
Date: Sat, 8 Jun 2024 12:55:12 -0300
Subject: Behavior of DatagramChannel vs ByteBuffers bound to MemorySessions
In-Reply-To: <697068fb-794b-407e-8691-e86ad1db434f@oracle.com>
References: <CAECsnDR8L-1Wq7HjZVH77x4NvY+yRtRVwpbvV98Kww=m+rCJFA@mail.gmail.com>
 <697068fb-794b-407e-8691-e86ad1db434f@oracle.com>
Message-ID: <CAECsnDQ+GmmzN_Tuc8uF7_cG=-dsL1bncDXthnCf=QKbi-X5WQ@mail.gmail.com>

@Alan,

Yes, Arenas can be closed at any time. Still, from my understanding, this
implicit restriction should only be imposed in code that does not invoke
JavaNioAccess::acquireSession explicitly, like in NioSocketImpl or
SocketChannelImpl.

Regarding safety issues, do you mean the possibility of the NIO layer
accessing an invalid address?

In the case of interleaving JavaNioAccess::acquireSession & Arena::close, I
think there are only two possible outcomes:

A)Arena is closed in Thread A, then Writer Thread B fails with
IllegalStateException
B)Writer Thread B acquires the session, then Thread A fails with
IllegalStateException

I don't think it is possible to reach a state where the NIO layer sees an
invalid (freed) address (unless of course the user code messes with jdk
internals by calling MemorySession::release0 explicitly in other thread).

As for "APIs that do asynchronous IO", are you refering to JDK internals
where the user has no control over the thread performing the write
operation? This is supported by, e.g., by AsynchronousSocketChannel

---
  var buffer =
Arena.ofShared().allocate(1024).asByteBuffer().putInt(42).flip();
  var q = new LinkedBlockingQueue<>();
  var asc = AsynchronousSocketChannel.open();
  asc.connect(new InetSocketAddress("openjdk.org", 443)).get();

  asc.write(buffer, null, new CompletionHandler<Integer, Void>() {

    public void completed(Integer result, Void attachment) {
      q.offer(result);
    }

    public void failed(Throwable exc, Void attachment) {
      exc.printStackTrace();
      q.offer(exc);
    }
  });

  System.out.println(q.take()); // 4
---

Regards

On Sat, Jun 8, 2024 at 5:22?AM Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 07/06/2024 18:00, Cleber Muramoto wrote:
> > Hello, I'd like to understand why a disconnected DatagramChannel does
> > not support direct buffers derived from MemorySegments created from
> > shared Arenas.
> >
> >
> A shared Arena can be closed at any time. There are safety guarantees
> that go along with that are problematic when doing I/O with byte buffers
> that are backed by a memory segment allocated. For APIs that do
> synchronous I/O then it may be possible to remove this restriction at
> some point. For APIs that do asynchronous I/O (as in initiate an I/O op
> on one thread, complete on another) then it is a harder problem.
>
> -Alan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240608/11006897/attachment.htm>

From Alan.Bateman at oracle.com  Sat Jun  8 19:35:58 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 8 Jun 2024 20:35:58 +0100
Subject: Behavior of DatagramChannel vs ByteBuffers bound to MemorySessions
In-Reply-To: <CAECsnDQ+GmmzN_Tuc8uF7_cG=-dsL1bncDXthnCf=QKbi-X5WQ@mail.gmail.com>
References: <CAECsnDR8L-1Wq7HjZVH77x4NvY+yRtRVwpbvV98Kww=m+rCJFA@mail.gmail.com>
 <697068fb-794b-407e-8691-e86ad1db434f@oracle.com>
 <CAECsnDQ+GmmzN_Tuc8uF7_cG=-dsL1bncDXthnCf=QKbi-X5WQ@mail.gmail.com>
Message-ID: <16f540e9-88fa-4645-84b7-f924fef6122c@oracle.com>



On 08/06/2024 16:55, Cleber Muramoto wrote:
> @Alan,
>
> Yes, Arenas can be closed at any time. Still, from my understanding, 
> this implicit restriction should only be imposed in code that does not 
> invoke JavaNioAccess::acquireSession explicitly, like in NioSocketImpl 
> or SocketChannelImpl.

All I/O operations defined by SocketChannel, DatagramSocket and 
FileChannel that read into a ByteBuffer or write from a ByteBuffer 
should be using acquire/releaseSession already. I checked all them and 
it's just the unconnected DatagramChannel send/receive that isn't using 
the right accessor to get the address. I should have spotted in when 
replying earlier. I have a test that exercises all the 16 I/O method 
with each of the 4 arena types. I'll create a bug for this.

NioSocketChannel is the SocketImpl for Socket/ServerSocket so it's 
byte[] rather than ByteBuffer.? SocketChannelImpl does use 
acquire/releaseSession for read/write methods on direct buffers. It 
exposes an adaptor view which the Socket API and thus byte[] rather than 
ByteBuffer.

-Alan

From alanb at openjdk.org  Mon Jun 10 07:22:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jun 2024 07:22:22 GMT
Subject: RFR: 8333849: (dc) DatagramChannel send/receive fails with UOE if
 buffer backed by memory segment allocated from shared arena
Message-ID: <X1jJFVLO4cExW3aaSW1GJIik19wzzFP_IsiqilNfIi0=.6e1e4929-1a75-4d4b-8631-95e6993822df@github.com>

DatagramChannel send/receive throw UOE if invoked with a ByteBuffer that is backed by a memory segment allocated from a shared arena.  These methods don't use IOUtil so was missed when the new accessor to get the buffer address was added. The issue is a remainder of lack of test coverage so I've added a test that exercises all read/write methods in the ByteChannel implementations.

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

Commit messages:
 - Initial commit

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

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

From dfuchs at openjdk.org  Mon Jun 10 11:00:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Jun 2024 11:00:11 GMT
Subject: RFR: 8333849: (dc) DatagramChannel send/receive fails with UOE if
 buffer backed by memory segment allocated from shared arena
In-Reply-To: <X1jJFVLO4cExW3aaSW1GJIik19wzzFP_IsiqilNfIi0=.6e1e4929-1a75-4d4b-8631-95e6993822df@github.com>
References: <X1jJFVLO4cExW3aaSW1GJIik19wzzFP_IsiqilNfIi0=.6e1e4929-1a75-4d4b-8631-95e6993822df@github.com>
Message-ID: <c_u5KKeCbFXk3ZsjfxlSnTvtqrnczOi10NoRJXailJA=.0f8f89f2-d54c-438c-9c0c-5ce1eabe07ef@github.com>

On Mon, 10 Jun 2024 06:43:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> DatagramChannel send/receive throw UOE if invoked with a ByteBuffer that is backed by a memory segment allocated from a shared arena.  These methods don't use IOUtil so was missed when the new accessor to get the buffer address was added. The issue is a remainder of lack of test coverage so I've added a test that exercises all read/write methods in the ByteChannel implementations.

Looks reasonable to me

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19618#pullrequestreview-2107464477

From alanb at openjdk.org  Mon Jun 10 12:50:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jun 2024 12:50:17 GMT
Subject: Integrated: 8333849: (dc) DatagramChannel send/receive fails with UOE
 if buffer backed by memory segment allocated from shared arena
In-Reply-To: <X1jJFVLO4cExW3aaSW1GJIik19wzzFP_IsiqilNfIi0=.6e1e4929-1a75-4d4b-8631-95e6993822df@github.com>
References: <X1jJFVLO4cExW3aaSW1GJIik19wzzFP_IsiqilNfIi0=.6e1e4929-1a75-4d4b-8631-95e6993822df@github.com>
Message-ID: <g8bI_zVcCJolt7rMwcjPi0KRq97yAyB6zpTL9_rA3Vk=.36bc6ac9-e316-47e7-a037-a1e6315b98e8@github.com>

On Mon, 10 Jun 2024 06:43:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> DatagramChannel send/receive throw UOE if invoked with a ByteBuffer that is backed by a memory segment allocated from a shared arena.  These methods don't use IOUtil so was missed when the new accessor to get the buffer address was added. The issue is a remainder of lack of test coverage so I've added a test that exercises all read/write methods in the ByteChannel implementations.

This pull request has now been integrated.

Changeset: e7dc76b5
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7dc76b5776e05082281fb640d1592479cfe9e6b
Stats:     509 lines in 2 files changed: 506 ins; 0 del; 3 mod

8333849: (dc) DatagramChannel send/receive fails with UOE if buffer backed by memory segment allocated from shared arena

Reviewed-by: dfuchs

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

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

From dfuchs at openjdk.org  Fri Jun 14 14:27:23 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Jun 2024 14:27:23 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager
Message-ID: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>

The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.

This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.

The original issue that this test tried to check for was:
https://bugs.openjdk.org/browse/JDK-6548464

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

Commit messages:
 - 8334297

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

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

From dfuchs at openjdk.org  Fri Jun 14 15:33:08 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Jun 2024 15:33:08 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v2]
In-Reply-To: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
Message-ID: <UYPAZwbNUB9dpsAY8mwEbXv7CrEeta6nwx4xpqsIBuM=.680ea5e3-9d54-4a34-b738-8d08b6d9d2ec@github.com>

> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
> 
> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
> 
> The original issue that this test tried to check for was:
> https://bugs.openjdk.org/browse/JDK-6548464

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Improve test for better coverage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19723/files
  - new: https://git.openjdk.org/jdk/pull/19723/files/79ca2ef4..77fdcf41

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

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

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

From dfuchs at openjdk.org  Fri Jun 14 15:45:21 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Jun 2024 15:45:21 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v2]
In-Reply-To: <UYPAZwbNUB9dpsAY8mwEbXv7CrEeta6nwx4xpqsIBuM=.680ea5e3-9d54-4a34-b738-8d08b6d9d2ec@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
 <UYPAZwbNUB9dpsAY8mwEbXv7CrEeta6nwx4xpqsIBuM=.680ea5e3-9d54-4a34-b738-8d08b6d9d2ec@github.com>
Message-ID: <cn1kX84qfokgCfZ7mRnVxnTQ2Rt_6m4SrjWVx96KtMU=.fec3dbdc-f277-4bd5-bf24-63aa0169cc03@github.com>

On Fri, 14 Jun 2024 15:33:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
>> 
>> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
>> 
>> The original issue that this test tried to check for was:
>> https://bugs.openjdk.org/browse/JDK-6548464
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve test for better coverage

There are two places of interest for this test where `SocketChannel` is closed: one is in `SocketChannel::connect`, if an `IOException` is thrown by e.g. `Net::connect`.
The other is in `SocketChannel::open(SocketAddress)`, if any `Throwable` is thrown by `SocketChannel::connect`.

The `SecurityException` was thrown by `checkRemote(SocketAddress)` called before entering the try/catch in `SocketChannel::connect`, and exercised that second path.

By analysing the code I noticed that `checkRemote` would also throw if an unresolved `InetSocketAddress` was passed to `SocketChannel::open(SocketAddress)` - which is closer to what the original test was testing, and would also exercise the latter path of execution.

I manually removed the `close()` call in `SocketChannel::open` and managed to make the test fail with `SoccketException("too many open files")`, but for that I had to increase the number of loops from 100000 to 250000 on my local machine. So I did that too.

I'm currently verifying the test is still stable in the CI, but I believe testing both paths - one with an unreachable port/address and one with an unresolved address is what we should do.

I have updated the test in consequence.

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

PR Comment: https://git.openjdk.org/jdk/pull/19723#issuecomment-2168296048

From dfuchs at openjdk.org  Fri Jun 14 15:57:29 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Jun 2024 15:57:29 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v3]
In-Reply-To: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
Message-ID: <8Ds-TySwonMv89dapQLZ8XBTpMy3mjTUUclxjiPCPkI=.057f8d9c-1b88-4d96-b670-02453ddf6918@github.com>

> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
> 
> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
> 
> The original issue that this test tried to check for was:
> https://bugs.openjdk.org/browse/JDK-6548464

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Minor cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19723/files
  - new: https://git.openjdk.org/jdk/pull/19723/files/77fdcf41..21b0641b

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

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

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

From alanb at openjdk.org  Fri Jun 14 16:37:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Jun 2024 16:37:21 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v3]
In-Reply-To: <8Ds-TySwonMv89dapQLZ8XBTpMy3mjTUUclxjiPCPkI=.057f8d9c-1b88-4d96-b670-02453ddf6918@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
 <8Ds-TySwonMv89dapQLZ8XBTpMy3mjTUUclxjiPCPkI=.057f8d9c-1b88-4d96-b670-02453ddf6918@github.com>
Message-ID: <RDvQxZV3pOTmIOoADNslrDbOEvWqA5pABmVosc5fOh4=.e37293ac-dcc1-4796-9454-31a6f78c8ee5@github.com>

On Fri, 14 Jun 2024 15:57:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
>> 
>> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
>> 
>> The original issue that this test tried to check for was:
>> https://bugs.openjdk.org/browse/JDK-6548464
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup

Looks good, assuming you've tested it on all platforms to ensure it is stable.

test/jdk/java/nio/channels/SocketChannel/OpenLeak.java line 73:

> 71: 
> 72:         System.out.println("Expecting Connection Refused for " + isa);
> 73:         System.out.println("Expecting UnresolvedAddressException for " + sa);

JUnit prints the STARTED/SUCCESSFUL/etc messages to System.err so you probably want the trace messages to go to the same stream.

test/jdk/java/nio/channels/SocketChannel/OpenLeak.java line 79:

> 77:                 try {
> 78:                     SocketChannel.open(sa);
> 79:                     throw new RuntimeException("This should not happen");

fail()

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19723#pullrequestreview-2118788580
PR Review Comment: https://git.openjdk.org/jdk/pull/19723#discussion_r1640069383
PR Review Comment: https://git.openjdk.org/jdk/pull/19723#discussion_r1640064610

From dfuchs at openjdk.org  Fri Jun 14 17:30:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Jun 2024 17:30:40 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v4]
In-Reply-To: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
Message-ID: <Xz_Azwww41C7ut-OM2RPScFCg1Pg4M7k0TTxv2mNCo8=.a5629a0d-9ced-4dc9-ae88-ceba6ad2bb38@github.com>

> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
> 
> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
> 
> The original issue that this test tried to check for was:
> https://bugs.openjdk.org/browse/JDK-6548464

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19723/files
  - new: https://git.openjdk.org/jdk/pull/19723/files/21b0641b..3451a702

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

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

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

From vtewari at openjdk.org  Fri Jun 14 17:33:12 2024
From: vtewari at openjdk.org (Vyom Tewari)
Date: Fri, 14 Jun 2024 17:33:12 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v3]
In-Reply-To: <8Ds-TySwonMv89dapQLZ8XBTpMy3mjTUUclxjiPCPkI=.057f8d9c-1b88-4d96-b670-02453ddf6918@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
 <8Ds-TySwonMv89dapQLZ8XBTpMy3mjTUUclxjiPCPkI=.057f8d9c-1b88-4d96-b670-02453ddf6918@github.com>
Message-ID: <WjKd9hc1w_5_S5l2wE6Syc9ri2BPcux9WL-vil_4V3A=.10b1d939-04f4-4616-b0ea-ff0ee659fe90@github.com>

On Fri, 14 Jun 2024 15:57:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
>> 
>> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
>> 
>> The original issue that this test tried to check for was:
>> https://bugs.openjdk.org/browse/JDK-6548464
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup

test/jdk/java/nio/channels/SocketChannel/OpenLeak.java line 44:

> 42: public class OpenLeak {
> 43: 
> 44:     private static final int MAX_LOOP = 250000;

Overall changes looks good to me but do you need to loop  25000 times ?.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19723#discussion_r1640149631

From dfuchs at openjdk.org  Fri Jun 14 17:42:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Jun 2024 17:42:17 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v3]
In-Reply-To: <WjKd9hc1w_5_S5l2wE6Syc9ri2BPcux9WL-vil_4V3A=.10b1d939-04f4-4616-b0ea-ff0ee659fe90@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
 <8Ds-TySwonMv89dapQLZ8XBTpMy3mjTUUclxjiPCPkI=.057f8d9c-1b88-4d96-b670-02453ddf6918@github.com>
 <WjKd9hc1w_5_S5l2wE6Syc9ri2BPcux9WL-vil_4V3A=.10b1d939-04f4-4616-b0ea-ff0ee659fe90@github.com>
Message-ID: <7eJN2dc2IISzG5Pmrutyvx9ZfFVhLtNfKW4uNqbu3zA=.547b3388-601a-40d2-a373-633c83e4d997@github.com>

On Fri, 14 Jun 2024 17:30:58 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor cleanup
>
> test/jdk/java/nio/channels/SocketChannel/OpenLeak.java line 44:
> 
>> 42: public class OpenLeak {
>> 43: 
>> 44:     private static final int MAX_LOOP = 250000;
> 
> Overall changes looks good to me but do you need to loop  25000 times ?.

Actually 250000 times ;-)

Yes - without the close() the test starts failling for me on my machine at around 247500 iterations. So if we really want to test that the issue the original test was trying to verify is fixed we need that, I believe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19723#discussion_r1640157053

From syan at openjdk.org  Sun Jun 16 08:19:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 16 Jun 2024 08:19:39 GMT
Subject: RFR: 8334339: CreationTime.java fails on alinux3
Message-ID: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>

Hi all,
  The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
  The testcase use /tmp directory to create the file and get the createtime of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the birth time on tmpfs.
  On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support birth time.

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

Commit messages:
 - 8334339: CreationTime.java fails on alinux3

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

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

From syan at openjdk.org  Sun Jun 16 15:01:29 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 16 Jun 2024 15:01:29 GMT
Subject: RFR: 8334339: CreationTime.java fails on alinux3 [v2]
In-Reply-To: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
Message-ID: <asTiaGsGyG-Fg1NhnjaaiPswqiHuINbtJyXp-YUFaJA=.dd2836dd-319d-4b6e-a4e1-304b30b4d47f@github.com>

> Hi all,
>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>   The testcase use /tmp directory to create the file and get the createtime of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
> 
>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
> 
>  The change has been verified on below env:
> 
> - [x] alinux3 run test CreationTime.java
> - [x] windows run test CreationTime.java
> 
> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)

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

 - delete an extra whitespace for line77
 - delete an extra whitespace for line : @test id=cwd
 - add function comment for supportBirthTimeOnLinux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19737/files
  - new: https://git.openjdk.org/jdk/pull/19737/files/42fec73f..0305b512

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

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

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

From alanb at openjdk.org  Mon Jun 17 09:29:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Jun 2024 09:29:12 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v2]
In-Reply-To: <asTiaGsGyG-Fg1NhnjaaiPswqiHuINbtJyXp-YUFaJA=.dd2836dd-319d-4b6e-a4e1-304b30b4d47f@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <asTiaGsGyG-Fg1NhnjaaiPswqiHuINbtJyXp-YUFaJA=.dd2836dd-319d-4b6e-a4e1-304b30b4d47f@github.com>
Message-ID: <tUO6z8-IsU-p9t3mEX_5-51cuBHNMNMObtItgPjHmJg=.ec6c44e2-8ad2-4a80-acdb-dfd11b9ea008@github.com>

On Sun, 16 Jun 2024 15:01:29 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>>   The testcase use /tmp directory to create the file and get the createtime(birth time) of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
>> 
>>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
>> 
>>  The change has been verified on below env:
>> 
>> - [x] alinux3 run test CreationTime.java
>> - [x] windows run test CreationTime.java
>> 
>> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
>> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)
>
> SendaoYan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - delete an extra whitespace for line77
>  - delete an extra whitespace for line : @test id=cwd
>  - add function comment for supportBirthTimeOnLinux

Would it be possible to say what `Files.getFileStore(file).type()` returns? The test has an existing method to skip and I'm wonder if that could be used rather than introducing another.

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

PR Comment: https://git.openjdk.org/jdk/pull/19737#issuecomment-2172855619

From syan at openjdk.org  Mon Jun 17 12:07:11 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Jun 2024 12:07:11 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v2]
In-Reply-To: <tUO6z8-IsU-p9t3mEX_5-51cuBHNMNMObtItgPjHmJg=.ec6c44e2-8ad2-4a80-acdb-dfd11b9ea008@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <asTiaGsGyG-Fg1NhnjaaiPswqiHuINbtJyXp-YUFaJA=.dd2836dd-319d-4b6e-a4e1-304b30b4d47f@github.com>
 <tUO6z8-IsU-p9t3mEX_5-51cuBHNMNMObtItgPjHmJg=.ec6c44e2-8ad2-4a80-acdb-dfd11b9ea008@github.com>
Message-ID: <fxjeWGRWT8XpPnmMs_jK3fyhlqYJcOS_BpY4CnVUneA=.68c15426-3abd-4b1c-8788-2da0c9ee26ed@github.com>

On Mon, 17 Jun 2024 09:26:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to say what `Files.getFileStore(file).type()` returns? The test has an existing method to skip and I'm wonder if that could be used rather than introducing another.

`Files.getFileStore(file).type()` returns `tmpfs`. But does it possible that the linux kernel can support `birth time` for `tmpfs`type files in future. I think it is more accurate to use the `stat` command to determine whether a file supports `birth` than to obtain the file type throuht `Files.getFileStore(file).type()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/19737#issuecomment-2173215538

From dfuchs at openjdk.org  Mon Jun 17 18:36:53 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Jun 2024 18:36:53 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v5]
In-Reply-To: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
Message-ID: <R-pt8rF2fuEIBFeA6KOmNYBLHv5GOPyr0UVdmMRrpbo=.ddf10676-3d3a-4155-beba-20063932ae02@github.com>

> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
> 
> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
> 
> The original issue that this test tried to check for was:
> https://bugs.openjdk.org/browse/JDK-6548464

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Refactor to ParameterizedTest. Do not test for refused connection on Windows Server 2016

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19723/files
  - new: https://git.openjdk.org/jdk/pull/19723/files/3451a702..69fd3e37

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

  Stats: 88 lines in 1 file changed: 48 ins; 15 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/19723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19723/head:pull/19723

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

From dfuchs at openjdk.org  Mon Jun 17 18:55:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Jun 2024 18:55:44 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v3]
In-Reply-To: <RDvQxZV3pOTmIOoADNslrDbOEvWqA5pABmVosc5fOh4=.e37293ac-dcc1-4796-9454-31a6f78c8ee5@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
 <8Ds-TySwonMv89dapQLZ8XBTpMy3mjTUUclxjiPCPkI=.057f8d9c-1b88-4d96-b670-02453ddf6918@github.com>
 <RDvQxZV3pOTmIOoADNslrDbOEvWqA5pABmVosc5fOh4=.e37293ac-dcc1-4796-9454-31a6f78c8ee5@github.com>
Message-ID: <1cMr3ZDDc1KCtm63VCibX5jf55d1TBW2yZwZrbRtJXU=.d1564fb5-e5b1-4f28-ac7c-5fd151ebfbf9@github.com>

On Fri, 14 Jun 2024 16:34:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor cleanup
>
> Looks good, assuming you've tested it on all platforms to ensure it is stable.

@AlanBateman My test campaign revealed that trying to connect to a reserved port on  the loopback didn't work for windows 2016 machines. I suspect that on that system you need to wait for the whole connect timeout before getting the connection refused exception.

I have reworked the test to only test with unresolved addresses on windows 2016, and we can use use the same technic of skipping the ConnectException if we find other platforms where this does not work out.

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

PR Comment: https://git.openjdk.org/jdk/pull/19723#issuecomment-2174203743

From alanb at openjdk.org  Tue Jun 18 07:05:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Jun 2024 07:05:11 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v5]
In-Reply-To: <R-pt8rF2fuEIBFeA6KOmNYBLHv5GOPyr0UVdmMRrpbo=.ddf10676-3d3a-4155-beba-20063932ae02@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
 <R-pt8rF2fuEIBFeA6KOmNYBLHv5GOPyr0UVdmMRrpbo=.ddf10676-3d3a-4155-beba-20063932ae02@github.com>
Message-ID: <UYZpb-JI4ioiqjhVya9C1kf8NHFIeyRmDZr0Sa_xgx0=.416b69bf-cdec-4a4c-b395-433c0b400ddf@github.com>

On Mon, 17 Jun 2024 18:36:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
>> 
>> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
>> 
>> The original issue that this test tried to check for was:
>> https://bugs.openjdk.org/browse/JDK-6548464
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to ParameterizedTest. Do not test for refused connection on Windows Server 2016

test/jdk/java/nio/channels/SocketChannel/OpenLeak.java line 109:

> 107:         cases.add(new Object[]{sa, UnresolvedAddressException.class});
> 108:         cases.add(new Object[]{isa, ConnectException.class});
> 109:         return cases;

A somewhat subjective comment but I don't think I would add the SocketAddress to the list of test cases when its value is null. So if there isn't a suitable port then it would just reduce the set of test cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19723#discussion_r1643933538

From dfuchs at openjdk.org  Tue Jun 18 11:13:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Jun 2024 11:13:10 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v5]
In-Reply-To: <UYZpb-JI4ioiqjhVya9C1kf8NHFIeyRmDZr0Sa_xgx0=.416b69bf-cdec-4a4c-b395-433c0b400ddf@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
 <R-pt8rF2fuEIBFeA6KOmNYBLHv5GOPyr0UVdmMRrpbo=.ddf10676-3d3a-4155-beba-20063932ae02@github.com>
 <UYZpb-JI4ioiqjhVya9C1kf8NHFIeyRmDZr0Sa_xgx0=.416b69bf-cdec-4a4c-b395-433c0b400ddf@github.com>
Message-ID: <KON4xMFHSFSVVcjv5cRS40HzNjeMUUVFIlDc6fr9SMs=.bc1e729b-7687-445b-bf9a-65e24a81c442@github.com>

On Tue, 18 Jun 2024 07:02:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor to ParameterizedTest. Do not test for refused connection on Windows Server 2016
>
> test/jdk/java/nio/channels/SocketChannel/OpenLeak.java line 109:
> 
>> 107:         cases.add(new Object[]{sa, UnresolvedAddressException.class});
>> 108:         cases.add(new Object[]{isa, ConnectException.class});
>> 109:         return cases;
> 
> A somewhat subjective comment but I don't think I would add the SocketAddress to the list of test cases when its value is null. So if there isn't a suitable port then it would just reduce the set of test cases.

The reason I do that is to record the testcase for ConnectException as aborted (Assumptions.abort will be called, and it will appear in the summary). But maybe that's not useful? There are only two test cases anyway: one for unresolved address and one for connection refused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19723#discussion_r1644272080

From alanb at openjdk.org  Tue Jun 18 11:43:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Jun 2024 11:43:14 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v5]
In-Reply-To: <KON4xMFHSFSVVcjv5cRS40HzNjeMUUVFIlDc6fr9SMs=.bc1e729b-7687-445b-bf9a-65e24a81c442@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
 <R-pt8rF2fuEIBFeA6KOmNYBLHv5GOPyr0UVdmMRrpbo=.ddf10676-3d3a-4155-beba-20063932ae02@github.com>
 <UYZpb-JI4ioiqjhVya9C1kf8NHFIeyRmDZr0Sa_xgx0=.416b69bf-cdec-4a4c-b395-433c0b400ddf@github.com>
 <KON4xMFHSFSVVcjv5cRS40HzNjeMUUVFIlDc6fr9SMs=.bc1e729b-7687-445b-bf9a-65e24a81c442@github.com>
Message-ID: <fUZQ9hr3df1Z3aQkyE5I8Cg8HGmYk2s1XKggEjhclQQ=.6a072347-d1fb-4b98-8e44-dc87c821869a@github.com>

On Tue, 18 Jun 2024 11:10:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/nio/channels/SocketChannel/OpenLeak.java line 109:
>> 
>>> 107:         cases.add(new Object[]{sa, UnresolvedAddressException.class});
>>> 108:         cases.add(new Object[]{isa, ConnectException.class});
>>> 109:         return cases;
>> 
>> A somewhat subjective comment but I don't think I would add the SocketAddress to the list of test cases when its value is null. So if there isn't a suitable port then it would just reduce the set of test cases.
>
> The reason I do that is to record the testcase for ConnectException as aborted (Assumptions.abort will be called, and it will appear in the summary). But maybe that's not useful? There are only two test cases anyway: one for unresolved address and one for connection refused.

Using assume to test the runtime or some configuration before running a test is fine. It's just a bit unusual here that the method source produces a test case that can't be used. I don't object to the current version, just a bit unusual to see this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19723#discussion_r1644322791

From dfuchs at openjdk.org  Tue Jun 18 13:54:28 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Jun 2024 13:54:28 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v6]
In-Reply-To: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
Message-ID: <Ql2AKf5dxGaj31L4i4iqwRMnpkibqFSkBKXnM5h34H0=.4ec90c47-fa8e-4448-a93f-231faab250c5@github.com>

> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
> 
> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
> 
> The original issue that this test tried to check for was:
> https://bugs.openjdk.org/browse/JDK-6548464

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback: prefer not generating test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19723/files
  - new: https://git.openjdk.org/jdk/pull/19723/files/69fd3e37..e2093a14

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

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

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

From dfuchs at openjdk.org  Tue Jun 18 14:02:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Jun 2024 14:02:11 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v5]
In-Reply-To: <fUZQ9hr3df1Z3aQkyE5I8Cg8HGmYk2s1XKggEjhclQQ=.6a072347-d1fb-4b98-8e44-dc87c821869a@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
 <R-pt8rF2fuEIBFeA6KOmNYBLHv5GOPyr0UVdmMRrpbo=.ddf10676-3d3a-4155-beba-20063932ae02@github.com>
 <UYZpb-JI4ioiqjhVya9C1kf8NHFIeyRmDZr0Sa_xgx0=.416b69bf-cdec-4a4c-b395-433c0b400ddf@github.com>
 <KON4xMFHSFSVVcjv5cRS40HzNjeMUUVFIlDc6fr9SMs=.bc1e729b-7687-445b-bf9a-65e24a81c442@github.com>
 <fUZQ9hr3df1Z3aQkyE5I8Cg8HGmYk2s1XKggEjhclQQ=.6a072347-d1fb-4b98-8e44-dc87c821869a@github.com>
Message-ID: <Ef1NmEB16Uc-_Ln-oCuVELgG8NFH646tWUlg1s24VQ4=.a1a071d1-5842-4a61-be03-cd3ae93ddc90@github.com>

On Tue, 18 Jun 2024 11:40:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The reason I do that is to record the testcase for ConnectException as aborted (Assumptions.abort will be called, and it will appear in the summary). But maybe that's not useful? There are only two test cases anyway: one for unresolved address and one for connection refused.
>
> Using assume to test the runtime or some configuration before running a test is fine. It's just a bit unusual here that the method source produces a test case that can't be used. I don't object to the current version, just a bit unusual to see this.

OK - I have changed it to not produce the test case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19723#discussion_r1644521117

From dfuchs at openjdk.org  Tue Jun 18 18:49:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Jun 2024 18:49:12 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v6]
In-Reply-To: <Ql2AKf5dxGaj31L4i4iqwRMnpkibqFSkBKXnM5h34H0=.4ec90c47-fa8e-4448-a93f-231faab250c5@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
 <Ql2AKf5dxGaj31L4i4iqwRMnpkibqFSkBKXnM5h34H0=.4ec90c47-fa8e-4448-a93f-231faab250c5@github.com>
Message-ID: <H_RfYJ4zBJzR3jh2yX2jgkH4cBtxDppOIhRX9bC0UyM=.1fdcd7cb-02ad-4db0-954a-d88d4cf83ead@github.com>

On Tue, 18 Jun 2024 13:54:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
>> 
>> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
>> 
>> The original issue that this test tried to check for was:
>> https://bugs.openjdk.org/browse/JDK-6548464
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: prefer not generating test case

If there are no more review comments I'll integrate tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/19723#issuecomment-2176743702

From alanb at openjdk.org  Tue Jun 18 19:17:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Jun 2024 19:17:20 GMT
Subject: RFR: 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java
 should not depend on SecurityManager [v6]
In-Reply-To: <Ql2AKf5dxGaj31L4i4iqwRMnpkibqFSkBKXnM5h34H0=.4ec90c47-fa8e-4448-a93f-231faab250c5@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
 <Ql2AKf5dxGaj31L4i4iqwRMnpkibqFSkBKXnM5h34H0=.4ec90c47-fa8e-4448-a93f-231faab250c5@github.com>
Message-ID: <y4x0YnBhb9OujX3EcwpRBeIwUn2PbEEAkiJf3WVv3sQ=.7c82c136-1ea6-48e9-85a8-b20c5b0697a0@github.com>

On Tue, 18 Jun 2024 13:54:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
>> 
>> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
>> 
>> The original issue that this test tried to check for was:
>> https://bugs.openjdk.org/browse/JDK-6548464
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: prefer not generating test case

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19723#pullrequestreview-2126292730

From dfuchs at openjdk.org  Wed Jun 19 10:57:14 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 19 Jun 2024 10:57:14 GMT
Subject: Integrated: 8334297: (so)
 java/nio/channels/SocketChannel/OpenLeak.java should not depend on
 SecurityManager
In-Reply-To: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
References: <nZILEVzXo1NFl0RLPXm77d073ztW8LeW4YYs2BtdPqs=.16a7307e-5acb-4ee6-971c-4d213328dc16@github.com>
Message-ID: <QlG1i5P1xU0Gstg90x4IpIJMuScOrXV652rJihH8Uro=.2435fff1-5093-49ad-bd13-7ec54cc377b8@github.com>

On Fri, 14 Jun 2024 14:21:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The test java/nio/channels/SocketChannel/OpenLeak.java depends on the SecurityManager to trigger an exception in SocketChannel::connect.
> 
> This change rewrites it to connect to a TCP reserved port instead, such as port 47, 51, or 61, in order to trigger a `ConnectException` instead of a `SecurityException`.
> 
> The original issue that this test tried to check for was:
> https://bugs.openjdk.org/browse/JDK-6548464

This pull request has now been integrated.

Changeset: 50bed6c6
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50bed6c67b1edd7736bdf79308d135a4e1047ff0
Stats:     93 lines in 1 file changed: 82 ins; 0 del; 11 mod

8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java should not depend on SecurityManager

Reviewed-by: alanb

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

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

From dfuchs at openjdk.org  Thu Jun 20 10:51:35 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Jun 2024 10:51:35 GMT
Subject: RFR: 8327370: (ch) sun.nio.ch.Poller.register throws AssertionError
Message-ID: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>

Please find here an almost trivial change that fixes an intermittent AssertionError observed in `sun.nio.ch.Poller`.

This change (in the mist of a bigger fix) was contributed by @AlanBateman to the loom repo two weeks ago.

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

Commit messages:
 - Fix mistake - catch Throwable to cover more cases
 - 8327370

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

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

From alanb at openjdk.org  Thu Jun 20 10:51:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jun 2024 10:51:35 GMT
Subject: RFR: 8327370: (ch) sun.nio.ch.Poller.register throws
 AssertionError
In-Reply-To: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>
References: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>
Message-ID: <J2IwQaG_pfrmsdeot7UcqXcqfqMUpU-gU5pSQG2tQYE=.49a2667a-6cba-46d6-9a29-f0a92cc755ae@github.com>

On Wed, 19 Jun 2024 13:36:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here an almost trivial change that fixes an intermittent AssertionError observed in `sun.nio.ch.Poller`.
> 
> This change (in the mist of a bigger fix) was contributed by @AlanBateman to the loom repo two weeks ago.

There have been a few sightings. One possible theory on macOS is that kevent(2) if failing with ENOMEM although it doesn't appear to have been caught in any logs.

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

PR Comment: https://git.openjdk.org/jdk/pull/19792#issuecomment-2178845690

From dfuchs at openjdk.org  Thu Jun 20 11:10:24 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Jun 2024 11:10:24 GMT
Subject: RFR: 8327370: (ch) sun.nio.ch.Poller.register throws
 AssertionError [v2]
In-Reply-To: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>
References: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>
Message-ID: <Nw3A8EdiKbYbhk_EltrYBm_GIn_Ig8Y_0C2C5KOoTwg=.3b48fd67-69f9-40b6-92d8-0b7bc3150d56@github.com>

> Please find here an almost trivial change that fixes an intermittent AssertionError observed in `sun.nio.ch.Poller`.
> 
> This change (in the mist of a bigger fix) was contributed by @AlanBateman to the loom repo two weeks ago.

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

 - Merge branch 'master' into JDK-8327370
 - Fix mistake - catch Throwable to cover more cases
 - 8327370

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19792/files
  - new: https://git.openjdk.org/jdk/pull/19792/files/33ed2820..1616b323

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

  Stats: 12211 lines in 64 files changed: 10322 ins; 958 del; 931 mod
  Patch: https://git.openjdk.org/jdk/pull/19792.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19792/head:pull/19792

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

From alanb at openjdk.org  Thu Jun 20 13:45:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jun 2024 13:45:13 GMT
Subject: RFR: 8327370: (ch) sun.nio.ch.Poller.register throws
 AssertionError [v2]
In-Reply-To: <Nw3A8EdiKbYbhk_EltrYBm_GIn_Ig8Y_0C2C5KOoTwg=.3b48fd67-69f9-40b6-92d8-0b7bc3150d56@github.com>
References: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>
 <Nw3A8EdiKbYbhk_EltrYBm_GIn_Ig8Y_0C2C5KOoTwg=.3b48fd67-69f9-40b6-92d8-0b7bc3150d56@github.com>
Message-ID: <T_Oh_Z4MBF8ix4lwgIl5ackuN75iURMF9OI3-_nWt6A=.aa4454ac-71ac-4a98-b810-f9a35be0436f@github.com>

On Thu, 20 Jun 2024 11:10:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here an almost trivial change that fixes an intermittent AssertionError observed in `sun.nio.ch.Poller`.
>> 
>> This change (in the mist of a bigger fix) was contributed by @AlanBateman to the loom repo two weeks ago.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8327370
>  - Fix mistake - catch Throwable to cover more cases
>  - 8327370

Thanks for fixing this in the main line, I assume it will need someone else to review.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19792#pullrequestreview-2130475618

From jpai at openjdk.org  Thu Jun 20 14:23:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Jun 2024 14:23:10 GMT
Subject: RFR: 8327370: (ch) sun.nio.ch.Poller.register throws
 AssertionError [v2]
In-Reply-To: <Nw3A8EdiKbYbhk_EltrYBm_GIn_Ig8Y_0C2C5KOoTwg=.3b48fd67-69f9-40b6-92d8-0b7bc3150d56@github.com>
References: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>
 <Nw3A8EdiKbYbhk_EltrYBm_GIn_Ig8Y_0C2C5KOoTwg=.3b48fd67-69f9-40b6-92d8-0b7bc3150d56@github.com>
Message-ID: <YQql3IP3HlD3H3Q5i2Ym1eXj0P3pgJkF4ezbFd6QoHo=.f527f52a-7097-4787-9f6c-17c97494ff41@github.com>

On Thu, 20 Jun 2024 11:10:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here an almost trivial change that fixes an intermittent AssertionError observed in `sun.nio.ch.Poller`.
>> 
>> This change (in the mist of a bigger fix) was contributed by @AlanBateman to the loom repo two weeks ago.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8327370
>  - Fix mistake - catch Throwable to cover more cases
>  - 8327370

The change looks reasonable to me and looking at the code that's the only place where an entry would be inserted into the map, so this change isn't needed in any other call sites.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19792#pullrequestreview-2130591414

From dfuchs at openjdk.org  Thu Jun 20 14:52:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Jun 2024 14:52:11 GMT
Subject: RFR: 8327370: (ch) sun.nio.ch.Poller.register throws
 AssertionError [v2]
In-Reply-To: <YQql3IP3HlD3H3Q5i2Ym1eXj0P3pgJkF4ezbFd6QoHo=.f527f52a-7097-4787-9f6c-17c97494ff41@github.com>
References: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>
 <Nw3A8EdiKbYbhk_EltrYBm_GIn_Ig8Y_0C2C5KOoTwg=.3b48fd67-69f9-40b6-92d8-0b7bc3150d56@github.com>
 <YQql3IP3HlD3H3Q5i2Ym1eXj0P3pgJkF4ezbFd6QoHo=.f527f52a-7097-4787-9f6c-17c97494ff41@github.com>
Message-ID: <kbXlD5nzLqPWBxy4hxy6PaWzlV-GgZbjI3g1duxaHho=.c112c29a-f0a1-4e16-9ecf-4ba10f584aae@github.com>

On Thu, 20 Jun 2024 14:20:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8327370
>>  - Fix mistake - catch Throwable to cover more cases
>>  - 8327370
>
> The change looks reasonable to me and looking at the code that's the only place where an entry would be inserted into the map, so this change isn't needed in any other call sites.

Thanks @jaikiran

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

PR Comment: https://git.openjdk.org/jdk/pull/19792#issuecomment-2180901350

From djelinski at openjdk.org  Thu Jun 20 18:51:12 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 20 Jun 2024 18:51:12 GMT
Subject: RFR: 8327370: (ch) sun.nio.ch.Poller.register throws
 AssertionError [v2]
In-Reply-To: <Nw3A8EdiKbYbhk_EltrYBm_GIn_Ig8Y_0C2C5KOoTwg=.3b48fd67-69f9-40b6-92d8-0b7bc3150d56@github.com>
References: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>
 <Nw3A8EdiKbYbhk_EltrYBm_GIn_Ig8Y_0C2C5KOoTwg=.3b48fd67-69f9-40b6-92d8-0b7bc3150d56@github.com>
Message-ID: <Wr_wlimCt00VM9BCmc1S35cqNx4IqRSburd5giRILXs=.ffa2d538-99ca-4c91-972c-d6fea274d4d4@github.com>

On Thu, 20 Jun 2024 11:10:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here an almost trivial change that fixes an intermittent AssertionError observed in `sun.nio.ch.Poller`.
>> 
>> This change (in the mist of a bigger fix) was contributed by @AlanBateman to the loom repo two weeks ago.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8327370
>  - Fix mistake - catch Throwable to cover more cases
>  - 8327370

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19792#pullrequestreview-2131134905

From dfuchs at openjdk.org  Fri Jun 21 09:46:14 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Jun 2024 09:46:14 GMT
Subject: RFR: 8327370: (ch) sun.nio.ch.Poller.register throws
 AssertionError [v2]
In-Reply-To: <Wr_wlimCt00VM9BCmc1S35cqNx4IqRSburd5giRILXs=.ffa2d538-99ca-4c91-972c-d6fea274d4d4@github.com>
References: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>
 <Nw3A8EdiKbYbhk_EltrYBm_GIn_Ig8Y_0C2C5KOoTwg=.3b48fd67-69f9-40b6-92d8-0b7bc3150d56@github.com>
 <Wr_wlimCt00VM9BCmc1S35cqNx4IqRSburd5giRILXs=.ffa2d538-99ca-4c91-972c-d6fea274d4d4@github.com>
Message-ID: <OVte8Qk2GXLRl9d3q5q7IMzHtZ_6jLFPLqxiJFpLgT0=.3695304e-b9d7-4b95-84c1-cc7d566240a4@github.com>

On Thu, 20 Jun 2024 18:48:03 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8327370
>>  - Fix mistake - catch Throwable to cover more cases
>>  - 8327370
>
> Marked as reviewed by djelinski (Reviewer).

Thanks @djelinski

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

PR Comment: https://git.openjdk.org/jdk/pull/19792#issuecomment-2182402154

From dfuchs at openjdk.org  Fri Jun 21 09:46:15 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Jun 2024 09:46:15 GMT
Subject: Integrated: 8327370: (ch) sun.nio.ch.Poller.register throws
 AssertionError
In-Reply-To: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>
References: <KggztVCeq38uUVRGzokaZO1SZXWsjJRdMITSNVUinf8=.2d4d8ae1-8f1c-4546-9ea2-ac7f3e739aeb@github.com>
Message-ID: <wV3O8UOz1Hsd3wtCNufV30zdNXer2CvXDeZ-6TSKwVE=.75461185-a950-490e-b3eb-f36590a7974e@github.com>

On Wed, 19 Jun 2024 13:36:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here an almost trivial change that fixes an intermittent AssertionError observed in `sun.nio.ch.Poller`.
> 
> This change (in the mist of a bigger fix) was contributed by @AlanBateman to the loom repo two weeks ago.

This pull request has now been integrated.

Changeset: d2bebffb
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d2bebffb1fd26fae4526afd33a818ee776b7102e
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8327370: (ch) sun.nio.ch.Poller.register throws AssertionError

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: alanb, jpai, djelinski

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

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

From alanb at openjdk.org  Fri Jun 21 14:56:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Jun 2024 14:56:10 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v2]
In-Reply-To: <fxjeWGRWT8XpPnmMs_jK3fyhlqYJcOS_BpY4CnVUneA=.68c15426-3abd-4b1c-8788-2da0c9ee26ed@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <asTiaGsGyG-Fg1NhnjaaiPswqiHuINbtJyXp-YUFaJA=.dd2836dd-319d-4b6e-a4e1-304b30b4d47f@github.com>
 <tUO6z8-IsU-p9t3mEX_5-51cuBHNMNMObtItgPjHmJg=.ec6c44e2-8ad2-4a80-acdb-dfd11b9ea008@github.com>
 <fxjeWGRWT8XpPnmMs_jK3fyhlqYJcOS_BpY4CnVUneA=.68c15426-3abd-4b1c-8788-2da0c9ee26ed@github.com>
Message-ID: <xK22_4ld2gbRnu_1SNCjMLS4Llt__7gYCWft8P2oY4g=.c87b7c6e-6e74-4562-b7d0-eace552f59ea@github.com>

On Mon, 17 Jun 2024 12:04:38 GMT, SendaoYan <syan at openjdk.org> wrote:

> In some [situation](https://serverfault.com/questions/1128612/birth-time-of-files-are-missing-if-file-is-created-in-a-logical-volume-with-size), the ext4 file type doesn't support `birth time`, so use `Files.getFileStore(file).type()` determine whether a file support `birth time` or not is not quite accurate.

The concern with forking stat is that it complicates the test and creates more things to go wrong. If the change could be reduced to just skipping when the creation time is 0 then I think it should be okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/19737#issuecomment-2182908239

From syan at openjdk.org  Fri Jun 21 15:23:43 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Jun 2024 15:23:43 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v3]
In-Reply-To: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
Message-ID: <3aT4i20gOza3LlaIntLF0EXhqKlAc6uq-GCwqpAVh2c=.60b874b5-9862-49d1-9bb2-a127fc2f5a66@github.com>

> Hi all,
>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>   The testcase use /tmp directory to create the file and get the createtime(birth time) of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
> 
>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
> 
>  The change has been verified on below env:
> 
> - [x] alinux3 run test CreationTime.java
> - [x] windows run test CreationTime.java
> 
> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)

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

 - delete unneeded import
 - If the file system doesn't support birth time, then skip this test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19737/files
  - new: https://git.openjdk.org/jdk/pull/19737/files/0305b512..5c274ad7

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

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

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

From syan at openjdk.org  Fri Jun 21 15:23:43 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Jun 2024 15:23:43 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v2]
In-Reply-To: <xK22_4ld2gbRnu_1SNCjMLS4Llt__7gYCWft8P2oY4g=.c87b7c6e-6e74-4562-b7d0-eace552f59ea@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <asTiaGsGyG-Fg1NhnjaaiPswqiHuINbtJyXp-YUFaJA=.dd2836dd-319d-4b6e-a4e1-304b30b4d47f@github.com>
 <tUO6z8-IsU-p9t3mEX_5-51cuBHNMNMObtItgPjHmJg=.ec6c44e2-8ad2-4a80-acdb-dfd11b9ea008@github.com>
 <fxjeWGRWT8XpPnmMs_jK3fyhlqYJcOS_BpY4CnVUneA=.68c15426-3abd-4b1c-8788-2da0c9ee26ed@github.com>
 <xK22_4ld2gbRnu_1SNCjMLS4Llt__7gYCWft8P2oY4g=.c87b7c6e-6e74-4562-b7d0-eace552f59ea@github.com>
Message-ID: <B0a8tds82M0aVTPRvQMmyS_bpwJuG3-SVRJfvC0FoMM=.740af43d-8273-4427-808e-eba70e57612d@github.com>

On Fri, 21 Jun 2024 14:53:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The concern with forking stat is that it complicates the test and creates more things to go wrong. If the change could be reduced to just skipping when the creation time is 0 then I think it should be okay.

Thanks for the review, the `stat` fork has been deleted.

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

PR Comment: https://git.openjdk.org/jdk/pull/19737#issuecomment-2182956372

From alanb at openjdk.org  Fri Jun 21 16:12:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Jun 2024 16:12:15 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v3]
In-Reply-To: <3aT4i20gOza3LlaIntLF0EXhqKlAc6uq-GCwqpAVh2c=.60b874b5-9862-49d1-9bb2-a127fc2f5a66@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <3aT4i20gOza3LlaIntLF0EXhqKlAc6uq-GCwqpAVh2c=.60b874b5-9862-49d1-9bb2-a127fc2f5a66@github.com>
Message-ID: <myOIjwEdnLPF6Fx8_R7HG0Gg_iEzZhGACTrayapam6s=.d5546652-9508-4d5c-b0cf-f86714006dfa@github.com>

On Fri, 21 Jun 2024 15:23:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>>   The testcase use /tmp directory to create the file and get the createtime(birth time) of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
>> 
>>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
>> 
>>  The change has been verified on below env:
>> 
>> - [x] alinux3 run test CreationTime.java
>> - [x] windows run test CreationTime.java
>> 
>> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
>> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - delete unneeded import
>  - If the file system doesn't support birth time, then skip this test

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 34:

> 32: 
> 33: /* @test id=cwd
> 34:  * @bug 8011536 8151430 8316304 8334339

You can drop the list of bugs in the second test description, it only need to be in the first one.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 37:

> 35:  * @summary Basic test for creationTime attribute on platforms/file systems
> 36:  *     that support it, test directory is JTwork/scratch. The JTwork/scratch
> 37:  *     directory maybe at diff disk partition to /tmp on linux

I think you should want to say that it tests using the test scratch directory.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 84:

> 82:             System.out.println("creationTime.toMillis() == " + creationTime.toMillis());
> 83:             // If the file system doesn't support birth time, then skip this test
> 84:             if (0 == creationTime.toMillis()) {

Can you change this to check == 0 rather than the Yoda style.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 148:

> 146:         // create temporary directory to run tests
> 147:         Path dir;
> 148:         if(0 == args.length) {

Can you change this to `if (args.length == 0)`  ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19737#discussion_r1649164827
PR Review Comment: https://git.openjdk.org/jdk/pull/19737#discussion_r1649165535
PR Review Comment: https://git.openjdk.org/jdk/pull/19737#discussion_r1649164310
PR Review Comment: https://git.openjdk.org/jdk/pull/19737#discussion_r1649163524

From syan at openjdk.org  Fri Jun 21 16:16:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Jun 2024 16:16:22 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v4]
In-Reply-To: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
Message-ID: <5Fp1t58ZuOXXk0qhJrGgBQdYEl9L538waGOkttAGHws=.1940237b-6f97-4390-b80e-60546e06ff77@github.com>

> Hi all,
>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>   The testcase use /tmp directory to create the file and get the createtime(birth time) of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
> 
>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
> 
>  The change has been verified on below env:
> 
> - [x] alinux3 run test CreationTime.java
> - [x] windows run test CreationTime.java
> 
> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)

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

  change to "check == 0"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19737/files
  - new: https://git.openjdk.org/jdk/pull/19737/files/5c274ad7..05fca192

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

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

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

From syan at openjdk.org  Fri Jun 21 16:16:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Jun 2024 16:16:23 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v3]
In-Reply-To: <myOIjwEdnLPF6Fx8_R7HG0Gg_iEzZhGACTrayapam6s=.d5546652-9508-4d5c-b0cf-f86714006dfa@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <3aT4i20gOza3LlaIntLF0EXhqKlAc6uq-GCwqpAVh2c=.60b874b5-9862-49d1-9bb2-a127fc2f5a66@github.com>
 <myOIjwEdnLPF6Fx8_R7HG0Gg_iEzZhGACTrayapam6s=.d5546652-9508-4d5c-b0cf-f86714006dfa@github.com>
Message-ID: <4YTELlySKf8MZdvp8DvwE083fSszsonXajwrwPdhEKI=.8b39c0d7-27bc-4c7c-9544-a51f464e6866@github.com>

On Fri, 21 Jun 2024 16:09:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - delete unneeded import
>>  - If the file system doesn't support birth time, then skip this test
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 34:
> 
>> 32: 
>> 33: /* @test id=cwd
>> 34:  * @bug 8011536 8151430 8316304 8334339
> 
> You can drop the list of bugs in the second test description, it only need to be in the first one.

Thanks for the review, the code has been changed.

> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 148:
> 
>> 146:         // create temporary directory to run tests
>> 147:         Path dir;
>> 148:         if(0 == args.length) {
> 
> Can you change this to `if (args.length == 0)`  ?

Thanks for the review, the code has been changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19737#discussion_r1649169782
PR Review Comment: https://git.openjdk.org/jdk/pull/19737#discussion_r1649169657

From syan at openjdk.org  Fri Jun 21 16:24:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Jun 2024 16:24:23 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v5]
In-Reply-To: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
Message-ID: <RAMR_nxq1ZaZrrUUlR3j-XKJf4UKwnUsJq_m-r6NSS4=.18bdf2b6-bbfc-48ad-b383-7a3442aa772f@github.com>

> Hi all,
>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>   The testcase use /tmp directory to create the file and get the createtime(birth time) of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
> 
>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
> 
>  The change has been verified on below env:
> 
> - [x] alinux3 run test CreationTime.java
> - [x] windows run test CreationTime.java
> 
> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)

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

 - drop the list of bugs in the second test description
 - update the @summary description

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19737/files
  - new: https://git.openjdk.org/jdk/pull/19737/files/05fca192..ea36354e

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

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

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

From syan at openjdk.org  Fri Jun 21 16:24:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Jun 2024 16:24:23 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v3]
In-Reply-To: <myOIjwEdnLPF6Fx8_R7HG0Gg_iEzZhGACTrayapam6s=.d5546652-9508-4d5c-b0cf-f86714006dfa@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <3aT4i20gOza3LlaIntLF0EXhqKlAc6uq-GCwqpAVh2c=.60b874b5-9862-49d1-9bb2-a127fc2f5a66@github.com>
 <myOIjwEdnLPF6Fx8_R7HG0Gg_iEzZhGACTrayapam6s=.d5546652-9508-4d5c-b0cf-f86714006dfa@github.com>
Message-ID: <ulN4B4Fzz92g0qrrIx3ibuG3ohn3PdZwqK1yZrpk-aI=.1cd47a61-3e00-4a29-9568-ea1b70e0b338@github.com>

On Fri, 21 Jun 2024 16:09:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - delete unneeded import
>>  - If the file system doesn't support birth time, then skip this test
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 34:
> 
>> 32: 
>> 33: /* @test id=cwd
>> 34:  * @bug 8011536 8151430 8316304 8334339
> 
> You can drop the list of bugs in the second test description, it only need to be in the first one.

Okey, the list of bugs in the second test description has been deleted.

> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 37:
> 
>> 35:  * @summary Basic test for creationTime attribute on platforms/file systems
>> 36:  *     that support it, test directory is JTwork/scratch. The JTwork/scratch
>> 37:  *     directory maybe at diff disk partition to /tmp on linux
> 
> I think you should want to say that it tests using the test scratch directory.

The @summary description has been updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19737#discussion_r1649177610
PR Review Comment: https://git.openjdk.org/jdk/pull/19737#discussion_r1649173952

From alanb at openjdk.org  Sat Jun 22 08:40:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 22 Jun 2024 08:40:18 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v5]
In-Reply-To: <RAMR_nxq1ZaZrrUUlR3j-XKJf4UKwnUsJq_m-r6NSS4=.18bdf2b6-bbfc-48ad-b383-7a3442aa772f@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <RAMR_nxq1ZaZrrUUlR3j-XKJf4UKwnUsJq_m-r6NSS4=.18bdf2b6-bbfc-48ad-b383-7a3442aa772f@github.com>
Message-ID: <RKonHg809QZHEjnhOkBDFUcJgIkh05uT2y9z9GPbci0=.52e48d4d-663c-42c0-bd55-3ff1983a2d98@github.com>

On Fri, 21 Jun 2024 16:24:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>>   The testcase use /tmp directory to create the file and get the createtime(birth time) of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
>> 
>>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
>> 
>>  The change has been verified on below env:
>> 
>> - [x] alinux3 run test CreationTime.java
>> - [x] windows run test CreationTime.java
>> 
>> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
>> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - drop the list of bugs in the second test description
>  - update the @summary description

I think this is okay. Yes it means that the test will pass if the the epoch is returned for the file creation time but it keeps the test simple.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 147:

> 145:         // create temporary directory to run tests
> 146:         Path dir;
> 147:         if(args.length == 0) {

Minor nit, missing space in "if(".

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19737#pullrequestreview-2133661035
PR Review Comment: https://git.openjdk.org/jdk/pull/19737#discussion_r1649602741

From syan at openjdk.org  Sat Jun 22 08:45:26 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Jun 2024 08:45:26 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v6]
In-Reply-To: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
Message-ID: <VGSqhUzVkPe7eBewJhwmzwjlcO1tVe0w8sIXndqS43w=.26bf98b7-1c89-4194-9eee-6c4345edd0a1@github.com>

> Hi all,
>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>   The testcase use /tmp directory to create the file and get the createtime(birth time) of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
> 
>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
> 
>  The change has been verified on below env:
> 
> - [x] alinux3 run test CreationTime.java
> - [x] windows run test CreationTime.java
> 
> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)

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

  add a whitespace after if

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19737/files
  - new: https://git.openjdk.org/jdk/pull/19737/files/ea36354e..fce6c980

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

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

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

From syan at openjdk.org  Sat Jun 22 08:45:26 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Jun 2024 08:45:26 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v5]
In-Reply-To: <RAMR_nxq1ZaZrrUUlR3j-XKJf4UKwnUsJq_m-r6NSS4=.18bdf2b6-bbfc-48ad-b383-7a3442aa772f@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <RAMR_nxq1ZaZrrUUlR3j-XKJf4UKwnUsJq_m-r6NSS4=.18bdf2b6-bbfc-48ad-b383-7a3442aa772f@github.com>
Message-ID: <cqtuh2mzysN6QGhoYy8y-NbCZbqn2_HZmDmyIxKK1Do=.54b8c80b-f021-4419-a906-853d11364911@github.com>

On Fri, 21 Jun 2024 16:24:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>>   The testcase use /tmp directory to create the file and get the createtime(birth time) of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
>> 
>>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
>> 
>>  The change has been verified on below env:
>> 
>> - [x] alinux3 run test CreationTime.java
>> - [x] windows run test CreationTime.java
>> 
>> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
>> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - drop the list of bugs in the second test description
>  - update the @summary description

Thanks for the review and suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/19737#issuecomment-2183931263

From syan at openjdk.org  Sat Jun 22 08:45:26 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Jun 2024 08:45:26 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v5]
In-Reply-To: <RKonHg809QZHEjnhOkBDFUcJgIkh05uT2y9z9GPbci0=.52e48d4d-663c-42c0-bd55-3ff1983a2d98@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <RAMR_nxq1ZaZrrUUlR3j-XKJf4UKwnUsJq_m-r6NSS4=.18bdf2b6-bbfc-48ad-b383-7a3442aa772f@github.com>
 <RKonHg809QZHEjnhOkBDFUcJgIkh05uT2y9z9GPbci0=.52e48d4d-663c-42c0-bd55-3ff1983a2d98@github.com>
Message-ID: <DlAApm8va1Mi4ykOEbpBMGz21LxUvaH-v5Wty1h8UoM=.d7266e77-ffbd-4b8d-85d0-f413c55402b2@github.com>

On Sat, 22 Jun 2024 08:37:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - drop the list of bugs in the second test description
>>  - update the @summary description
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 147:
> 
>> 145:         // create temporary directory to run tests
>> 146:         Path dir;
>> 147:         if(args.length == 0) {
> 
> Minor nit, missing space in "if(".

Sorry, the space has been added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19737#discussion_r1649604104

From syan at openjdk.org  Sat Jun 22 08:57:10 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Jun 2024 08:57:10 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v6]
In-Reply-To: <VGSqhUzVkPe7eBewJhwmzwjlcO1tVe0w8sIXndqS43w=.26bf98b7-1c89-4194-9eee-6c4345edd0a1@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <VGSqhUzVkPe7eBewJhwmzwjlcO1tVe0w8sIXndqS43w=.26bf98b7-1c89-4194-9eee-6c4345edd0a1@github.com>
Message-ID: <aTS5JWRaXF7kEqwrl2F2l9piP9B_bj530hRx0nJXVfc=.4be23c2d-2dd3-4e1f-ad14-e429b00064a6@github.com>

On Sat, 22 Jun 2024 08:45:26 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>>   The testcase use /tmp directory to create the file and get the createtime(birth time) of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
>> 
>>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
>> 
>>  The change has been verified on below env:
>> 
>> - [x] alinux3 run test CreationTime.java
>> - [x] windows run test CreationTime.java
>> 
>> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
>> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a whitespace after if

The GHA test [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/9616709215/job/26527909008) report a intermitent failure, I has created a [issue](https://bugs.openjdk.org/browse/JDK-8334760) to record this failure. It's unrelated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/19737#issuecomment-2183950361

From alanb at openjdk.org  Sat Jun 22 08:57:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 22 Jun 2024 08:57:10 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v6]
In-Reply-To: <aTS5JWRaXF7kEqwrl2F2l9piP9B_bj530hRx0nJXVfc=.4be23c2d-2dd3-4e1f-ad14-e429b00064a6@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <VGSqhUzVkPe7eBewJhwmzwjlcO1tVe0w8sIXndqS43w=.26bf98b7-1c89-4194-9eee-6c4345edd0a1@github.com>
 <aTS5JWRaXF7kEqwrl2F2l9piP9B_bj530hRx0nJXVfc=.4be23c2d-2dd3-4e1f-ad14-e429b00064a6@github.com>
Message-ID: <QfsanzngPca4w1L0fczWkNeA6GV2RmfR03_LpU2OQ7Q=.9c1faf40-48d2-44a2-93fe-f201e32211c1@github.com>

On Sat, 22 Jun 2024 08:52:15 GMT, SendaoYan <syan at openjdk.org> wrote:

> The GHA test [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/9616709215/job/26527909008) report a intermitent failure, I has created a [issue](https://bugs.openjdk.org/browse/JDK-8334760) to record this failure. It's unrelated to this PR.

Okay, but just to say that the tests for this are in tier2 so not run by the GHA.

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

PR Comment: https://git.openjdk.org/jdk/pull/19737#issuecomment-2183950851

From syan at openjdk.org  Sun Jun 23 18:03:14 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 23 Jun 2024 18:03:14 GMT
Subject: Integrated: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3
In-Reply-To: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
Message-ID: <najGFjT5waEjQbrDgd9p74e_9FTBMfamoPV2E7KGH1Q=.07dde22e-ca06-4143-b6aa-251cebfd394c@github.com>

On Sun, 16 Jun 2024 08:15:27 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>   The testcase use /tmp directory to create the file and get the createtime(birth time) of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
> 
>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
> 
>  The change has been verified on below env:
> 
> - [x] alinux3 run test CreationTime.java
> - [x] windows run test CreationTime.java
> 
> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)

This pull request has now been integrated.

Changeset: 7baddc20
Author:    SendaoYan <syan at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7baddc202a9ab2b85401aa05f827678b514ebf55
Stats:     29 lines in 1 file changed: 21 ins; 0 del; 8 mod

8334339: Test java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on alinux3

Reviewed-by: alanb

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

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

From syan at openjdk.org  Mon Jun 24 03:09:20 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 24 Jun 2024 03:09:20 GMT
Subject: RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3 [v6]
In-Reply-To: <VGSqhUzVkPe7eBewJhwmzwjlcO1tVe0w8sIXndqS43w=.26bf98b7-1c89-4194-9eee-6c4345edd0a1@github.com>
References: <QRyG-2yLwVCMKVN64JZWyGpZ6WfiRRvdCQkMTo0ZeBE=.b58d2d90-f59b-46b6-b90b-1ee69ea193bb@github.com>
 <VGSqhUzVkPe7eBewJhwmzwjlcO1tVe0w8sIXndqS43w=.26bf98b7-1c89-4194-9eee-6c4345edd0a1@github.com>
Message-ID: <B6_EekMPRfX_pWsGqXkjRFatodkMfgc5LzRAQxkUjgk=.359dc9b3-4a01-4458-b10c-766036baf0f1@github.com>

On Sat, 22 Jun 2024 08:45:26 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The testcase `java/nio/file/attribute/BasicFileAttributeView/CreationTime.java` fails on alinux3(alibaba cloud linux version 3) after [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304).
>>   The testcase use /tmp directory to create the file and get the createtime(birth time) of this file. But on alinux3(alibaba cloud linux version 3), the /tmp is mount as tmpfs, it's not a real physic disk paitition, it's mount from RAM, and the alinux3 doesn't support get the `birth time` on tmpfs.
>>   On ubuntu 22, when I create a file on /dev/shm(it's also a tmpfs type partition), stat also doesn't support `birth time`.
>>   According to the [Java API doc](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/attribute/BasicFileAttributes.html#creationTime()), If the file system implementation does not support a time stamp to indicate the time when the file was created, the creationTime() API return the epoch (1970-01-01T00:00:00Z).
>> 
>>   So in this PR, if the test directory(on linux the test directory is /tmp) doesn't support `birth time`, the test throw a jtreg.SkippedException, rather than report a failure.
>>   And in this PR, I create a new test, change the test directory from /tmp to `pwd`, which the current work directory maybe at diffrent partition to /tmp, and the current work directory support `birth time` possibly.
>> 
>>  The change has been verified on below env:
>> 
>> - [x] alinux3 run test CreationTime.java
>> - [x] windows run test CreationTime.java
>> 
>> [windows-CreationTime.java.log](https://github.com/user-attachments/files/15857148/windows-CreationTime.java.log)
>> [alinux3-CreationTime.java.log](https://github.com/user-attachments/files/15857149/alinux3-CreationTime.java.log)
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a whitespace after if

Thanks for the sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/19737#issuecomment-2185500822

From syan at openjdk.org  Mon Jun 24 03:12:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 24 Jun 2024 03:12:39 GMT
Subject: [jdk23] RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3
Message-ID: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>

Hi all,

This pull request contains a backport of commit [7baddc20](https://github.com/openjdk/jdk/commit/7baddc202a9ab2b85401aa05f827678b514ebf55) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by SendaoYan on 23 Jun 2024 and was reviewed by Alan Bateman.

Thanks!

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

Commit messages:
 - Backport 7baddc202a9ab2b85401aa05f827678b514ebf55

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

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

From jpai at openjdk.org  Tue Jun 25 11:37:37 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Jun 2024 11:37:37 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result in a
 Selector doing the final close before concurrent I/O on channel has completed
Message-ID: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>

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

Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 

The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 

A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.

A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.

Another round of tier testing with these changes is currently in progress.

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

Commit messages:
 - reduce the chances of JavaNioAccess already being looked up and cached by SelectableChannel implementations
 - 8334719: add test
 - 8334719: Alan's patch for kill() in SelectableChannels

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

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

From alanb at openjdk.org  Tue Jun 25 11:49:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Jun 2024 11:49:11 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed
In-Reply-To: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
Message-ID: <q9b2tSbm2QVmps7o5PgmM4ChOF7Oyaa33-ZsMcL6jts=.9b845674-d571-4502-bae4-2401ca970ee7@github.com>

On Tue, 25 Jun 2024 11:31:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
> 
> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
> 
> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
> 
> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
> 
> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
> 
> Another round of tier testing with these changes is currently in progress.

test/jdk/java/nio/channels/Selector/DeferredCloseTest.java line 466:

> 464: 
> 465:     private static final class DelayInjectingNIOAccess implements JavaNioAccess {
> 466:         private final JavaNioAccess realJavaNioAccess = SharedSecrets.getJavaNioAccess();

We can't have tests implementing this interface as it puts on a tax on every change to this interface (it changes regular). So I think we need to drop this and come up with an another way to test this scenario.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1652652909

From jpai at openjdk.org  Tue Jun 25 11:53:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Jun 2024 11:53:11 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed
In-Reply-To: <q9b2tSbm2QVmps7o5PgmM4ChOF7Oyaa33-ZsMcL6jts=.9b845674-d571-4502-bae4-2401ca970ee7@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <q9b2tSbm2QVmps7o5PgmM4ChOF7Oyaa33-ZsMcL6jts=.9b845674-d571-4502-bae4-2401ca970ee7@github.com>
Message-ID: <dW5zWPXbxD2a1crzNXw8QvLLdzG4s4ew3WketJPJwis=.de0b8dea-4266-4842-9c48-184bb7e11042@github.com>

On Tue, 25 Jun 2024 11:47:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> test/jdk/java/nio/channels/Selector/DeferredCloseTest.java line 466:
> 
>> 464: 
>> 465:     private static final class DelayInjectingNIOAccess implements JavaNioAccess {
>> 466:         private final JavaNioAccess realJavaNioAccess = SharedSecrets.getJavaNioAccess();
> 
> We can't have tests implementing this interface as it puts on a tax on every change to this interface (it changes regular). So I think we need to drop this and come up with an another way to test this scenario.

Understood. I'll take a look at the code and see what else we can do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1652658010

From syan at openjdk.org  Tue Jun 25 12:37:13 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 25 Jun 2024 12:37:13 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v2]
In-Reply-To: <TQnAzFlZOagZspITuoliliNBsmAsNDixSwBDkSmB7Ts=.be11e8bc-fa75-4eae-b2df-4b55f002a252@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <TQnAzFlZOagZspITuoliliNBsmAsNDixSwBDkSmB7Ts=.be11e8bc-fa75-4eae-b2df-4b55f002a252@github.com>
Message-ID: <lMOkrFfhDocm1i7GSqJ3SSS8LSFytDbwk-_QTy3VzTM=.0834ef4e-a3db-4bc6-8fd9-bc2cc43427cf@github.com>

On Tue, 28 May 2024 03:11:19 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jbs8332535
>  - 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java as intermittent
>    
>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

Hi, can anyone review this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2188816925

From jpai at openjdk.org  Tue Jun 25 13:55:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Jun 2024 13:55:47 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v2]
In-Reply-To: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
Message-ID: <NH537dhzvmUi-DelmJZUQjGAlwWoIHfB7xXf9yIEMz0=.7e803ffe-796a-469d-a6ac-b5afae24686d@github.com>

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
> 
> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
> 
> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
> 
> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
> 
> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
> 
> Another round of tier testing with these changes is currently in progress.

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

  don't inject NIO_ACCESS instead patch InetSocketAddress to introduce crafted delays

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19879/files
  - new: https://git.openjdk.org/jdk/pull/19879/files/2c254a3c..ae041539

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

  Stats: 393 lines in 2 files changed: 237 ins; 134 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/19879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19879/head:pull/19879

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

From jpai at openjdk.org  Tue Jun 25 13:58:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Jun 2024 13:58:10 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed
In-Reply-To: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
Message-ID: <5LjZlWqFzRhUijC3lfr3NtJQSjqrmibnEqgvLQMsrMw=.de005474-97e2-478d-832f-7361d3919fc1@github.com>

On Tue, 25 Jun 2024 11:31:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
> 
> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
> 
> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
> 
> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
> 
> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
> 
> Another round of tier testing with these changes is currently in progress.

Alan suggested that in this new test, we use a different class/API that isn't subject to frequent changes, unlike the `JavaNIOAccess`.

Based on Alan's suggestion of patching `InetSocketAddress` in this test, I was able to introduce delays at certain places within the patched `InetSocketAddress`. The updated test continues to consistently reproduce the failures in DatagramChannel, without the fix proposed in this PR. The test then passes with the proposed fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/19879#issuecomment-2189031001

From dfuchs at openjdk.org  Tue Jun 25 14:51:13 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Jun 2024 14:51:13 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v2]
In-Reply-To: <TQnAzFlZOagZspITuoliliNBsmAsNDixSwBDkSmB7Ts=.be11e8bc-fa75-4eae-b2df-4b55f002a252@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <TQnAzFlZOagZspITuoliliNBsmAsNDixSwBDkSmB7Ts=.be11e8bc-fa75-4eae-b2df-4b55f002a252@github.com>
Message-ID: <SHqreig8OALcPQkLG32k7hlAYbZ_eL52yUPFFkYdZ6E=.4227445d-a6e6-4cdd-a653-d3691203501d@github.com>

On Tue, 28 May 2024 03:11:19 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jbs8332535
>  - 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java as intermittent
>    
>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

test/jdk/java/nio/channels/DatagramChannel/Loopback.java line 164:

> 162:                             System.out.format("received %s from %s%n", dst, sender);
> 163:                             senderPort = ((InetSocketAddress) sender).getPort();
> 164:                             assertTrue(senderPort != localPort, "Unexpected message: localPort=" + localPort);

I wonder if we should add some entropy to the message content and discard any message that we receive whose payload doesn't match what we expect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1652979834

From dfuchs at openjdk.org  Tue Jun 25 15:01:18 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Jun 2024 15:01:18 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v2]
In-Reply-To: <NH537dhzvmUi-DelmJZUQjGAlwWoIHfB7xXf9yIEMz0=.7e803ffe-796a-469d-a6ac-b5afae24686d@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <NH537dhzvmUi-DelmJZUQjGAlwWoIHfB7xXf9yIEMz0=.7e803ffe-796a-469d-a6ac-b5afae24686d@github.com>
Message-ID: <Fpp6Vu4993ZxgTF2p0uY4Et3LzYla7Nd8O2-2H5rdkw=.1ebb1f27-bde7-4317-acff-d252f53d7401@github.com>

On Tue, 25 Jun 2024 13:55:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't inject NIO_ACCESS instead patch InetSocketAddress to introduce crafted delays

The new patched `InetSocketAddress` is probably going to be used by all other tests in the `test/jdk/java/nio/channels/Selector/` directory. It might be prudent to either move the patched `InetSocketAddress` in its own library (move it to a subdirectory of `test/jdk/java/nio/channels/Selector/` and build that directory explicitely as a library in the tests that require it), or even safer move the new test in its own directory alogside with the patched `InetSocketAddress`.

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

PR Comment: https://git.openjdk.org/jdk/pull/19879#issuecomment-2189188328

From alanb at openjdk.org  Tue Jun 25 15:22:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Jun 2024 15:22:15 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v2]
In-Reply-To: <NH537dhzvmUi-DelmJZUQjGAlwWoIHfB7xXf9yIEMz0=.7e803ffe-796a-469d-a6ac-b5afae24686d@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <NH537dhzvmUi-DelmJZUQjGAlwWoIHfB7xXf9yIEMz0=.7e803ffe-796a-469d-a6ac-b5afae24686d@github.com>
Message-ID: <EpfROzvltAwz26peLXzJGUj6-JxvANLgB_imH5RhUEU=.2f42fb95-99ad-4314-b7b5-1a6aa52cefe7@github.com>

On Tue, 25 Jun 2024 13:55:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't inject NIO_ACCESS instead patch InetSocketAddress to introduce crafted delays

test/jdk/java/nio/channels/Selector/java.base/java/net/InetSocketAddress.java line 39:

> 37:             return false;
> 38:         }
> 39:     };

A simpler way to do this is to just add a setDelay method or even a constructor that allows the delay to be specified when creating the object.  That will allow the ThredLocal to go away and make the test a bit simpler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1653031412

From alanb at openjdk.org  Tue Jun 25 15:25:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Jun 2024 15:25:13 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v2]
In-Reply-To: <NH537dhzvmUi-DelmJZUQjGAlwWoIHfB7xXf9yIEMz0=.7e803ffe-796a-469d-a6ac-b5afae24686d@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <NH537dhzvmUi-DelmJZUQjGAlwWoIHfB7xXf9yIEMz0=.7e803ffe-796a-469d-a6ac-b5afae24686d@github.com>
Message-ID: <r7IXRRujtKpOXf4IJKjEPM3GXZSLsa4qoF09kmGJ7NI=.f6d2cea1-05a5-41e0-a44b-4a4c83c02faf@github.com>

On Tue, 25 Jun 2024 13:55:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't inject NIO_ACCESS instead patch InetSocketAddress to introduce crafted delays

test/jdk/java/nio/channels/Selector/DeferredCloseTest.java line 162:

> 160:                     // register the DatagramChannel with a selector
> 161:                     // (doesn't matter the interestOps)
> 162:                     final var key = dc.register(sel, SelectionKey.OP_READ);

The type on the LHS may not be obvious to future maintainers so I think use SelectionKey instead of var here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1653035912

From syan at openjdk.org  Tue Jun 25 15:53:12 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 25 Jun 2024 15:53:12 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v2]
In-Reply-To: <SHqreig8OALcPQkLG32k7hlAYbZ_eL52yUPFFkYdZ6E=.4227445d-a6e6-4cdd-a653-d3691203501d@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <TQnAzFlZOagZspITuoliliNBsmAsNDixSwBDkSmB7Ts=.be11e8bc-fa75-4eae-b2df-4b55f002a252@github.com>
 <SHqreig8OALcPQkLG32k7hlAYbZ_eL52yUPFFkYdZ6E=.4227445d-a6e6-4cdd-a653-d3691203501d@github.com>
Message-ID: <1_e0G5YxgY2huPkhpFwcenQfhqUfnyu4eOGXBKLvcXk=.cb113aa4-390b-42bc-8269-e7469e0353e0@github.com>

On Tue, 25 Jun 2024 14:48:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into jbs8332535
>>  - 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java as intermittent
>>    
>>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>
>
> test/jdk/java/nio/channels/DatagramChannel/Loopback.java line 164:
> 
>> 162:                             System.out.format("received %s from %s%n", dst, sender);
>> 163:                             senderPort = ((InetSocketAddress) sender).getPort();
>> 164:                             assertTrue(senderPort != localPort, "Unexpected message: localPort=" + localPort);
> 
> I wonder if we should add some entropy to the message content and discard any message that we receive whose payload doesn't match what we expect.

Do you mean like this:

-            ByteBuffer src = ByteBuffer.wrap("hello".getBytes("UTF-8"));
+            String str = "hello integer" + new Random().nextInt(10000);
+            ByteBuffer src = ByteBuffer.wrap(str.getBytes("UTF-8"));

And I don't known how to discard meaasge doesn't match what we expect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1653092896

From jpai at openjdk.org  Tue Jun 25 15:57:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Jun 2024 15:57:10 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v2]
In-Reply-To: <Fpp6Vu4993ZxgTF2p0uY4Et3LzYla7Nd8O2-2H5rdkw=.1ebb1f27-bde7-4317-acff-d252f53d7401@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <NH537dhzvmUi-DelmJZUQjGAlwWoIHfB7xXf9yIEMz0=.7e803ffe-796a-469d-a6ac-b5afae24686d@github.com>
 <Fpp6Vu4993ZxgTF2p0uY4Et3LzYla7Nd8O2-2H5rdkw=.1ebb1f27-bde7-4317-acff-d252f53d7401@github.com>
Message-ID: <9S3ai5vFntooIBbUc1WN_Zx6OjJ2w-JrUrTYWwD_gFY=.34b8ed38-86f8-444d-96ce-805da3cbaac9@github.com>

On Tue, 25 Jun 2024 14:57:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The new patched `InetSocketAddress` is probably going to be used by all other tests in the `test/jdk/java/nio/channels/Selector/` directory.

I was under the impression that it only gets used if the test explicitly states `@compile/module=java.base java/net/InetSocketAddress.java` in its test definition and then jtreg would add the following to the test launch command:


--patch-module java.base=jdk/JTwork/classes/0/java/nio/channels/Selector/DeferredCloseTest.d/patches/java.base


> or even safer move the new test in its own directory alogside with the patched InetSocketAddress.

I think this is safer. I'll follow this and create a  new test directory under the existing `Selector` one.

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

PR Comment: https://git.openjdk.org/jdk/pull/19879#issuecomment-2189330300

From jpai at openjdk.org  Tue Jun 25 16:35:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Jun 2024 16:35:10 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v2]
In-Reply-To: <EpfROzvltAwz26peLXzJGUj6-JxvANLgB_imH5RhUEU=.2f42fb95-99ad-4314-b7b5-1a6aa52cefe7@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <NH537dhzvmUi-DelmJZUQjGAlwWoIHfB7xXf9yIEMz0=.7e803ffe-796a-469d-a6ac-b5afae24686d@github.com>
 <EpfROzvltAwz26peLXzJGUj6-JxvANLgB_imH5RhUEU=.2f42fb95-99ad-4314-b7b5-1a6aa52cefe7@github.com>
Message-ID: <CNPVrTEXimQiUkqoa7pK78aFOei4nyvyolajDk8HzZc=.cc4b142e-0fbd-44b6-b52e-e1178004316f@github.com>

On Tue, 25 Jun 2024 15:19:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   don't inject NIO_ACCESS instead patch InetSocketAddress to introduce crafted delays
>
> test/jdk/java/nio/channels/Selector/java.base/java/net/InetSocketAddress.java line 39:
> 
>> 37:             return false;
>> 38:         }
>> 39:     };
> 
> A simpler way to do this is to just add a setDelay method or even a constructor that allows the delay to be specified when creating the object.  That will allow the ThredLocal to go away and make the test a bit simpler.

The use of ThreadLocal was to add fine grained delays to avoid delaying all the places where InetSocketAddress gets used and increasing the test execution time. I will remove the ThreadLocal and see how big an impact it has on test durations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1653158349

From dfuchs at openjdk.org  Tue Jun 25 17:26:20 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Jun 2024 17:26:20 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v2]
In-Reply-To: <1_e0G5YxgY2huPkhpFwcenQfhqUfnyu4eOGXBKLvcXk=.cb113aa4-390b-42bc-8269-e7469e0353e0@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <TQnAzFlZOagZspITuoliliNBsmAsNDixSwBDkSmB7Ts=.be11e8bc-fa75-4eae-b2df-4b55f002a252@github.com>
 <SHqreig8OALcPQkLG32k7hlAYbZ_eL52yUPFFkYdZ6E=.4227445d-a6e6-4cdd-a653-d3691203501d@github.com>
 <1_e0G5YxgY2huPkhpFwcenQfhqUfnyu4eOGXBKLvcXk=.cb113aa4-390b-42bc-8269-e7469e0353e0@github.com>
Message-ID: <6bBh41jUgc6-zMA8rvWwa6EOMjRW50dQwR5d99yDeXA=.2e0ea8d0-7e53-40f6-b145-771ac679ae32@github.com>

On Tue, 25 Jun 2024 15:49:50 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/nio/channels/DatagramChannel/Loopback.java line 164:
>> 
>>> 162:                             System.out.format("received %s from %s%n", dst, sender);
>>> 163:                             senderPort = ((InetSocketAddress) sender).getPort();
>>> 164:                             assertTrue(senderPort != localPort, "Unexpected message: localPort=" + localPort);
>> 
>> I wonder if we should add some entropy to the message content and discard any message that we receive whose payload doesn't match what we expect.
>
> Do you mean like this:
> 
> -            ByteBuffer src = ByteBuffer.wrap("hello".getBytes("UTF-8"));
> +            String str = "hello integer" + new Random().nextInt(10000);
> +            ByteBuffer src = ByteBuffer.wrap(str.getBytes("UTF-8"));
> 
> And I don't known how to discard meaasge doesn't match what we expect.

Yes - something like that. System.nanoTime() could work too.
By discard, I mean compare the content of `dst` with what was put in `src` - and if it doesn't match, clear `dst` and continue to go back to select() without even looking at the sender port. You may want to adjust the timeout you pass to select the second time around.
Rationale is: if the payloads do not match then we're just receiving some stray packet probably sent by another (test?) process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1653247164

From alanb at openjdk.org  Tue Jun 25 18:17:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Jun 2024 18:17:10 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v2]
In-Reply-To: <9S3ai5vFntooIBbUc1WN_Zx6OjJ2w-JrUrTYWwD_gFY=.34b8ed38-86f8-444d-96ce-805da3cbaac9@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <NH537dhzvmUi-DelmJZUQjGAlwWoIHfB7xXf9yIEMz0=.7e803ffe-796a-469d-a6ac-b5afae24686d@github.com>
 <Fpp6Vu4993ZxgTF2p0uY4Et3LzYla7Nd8O2-2H5rdkw=.1ebb1f27-bde7-4317-acff-d252f53d7401@github.com>
 <9S3ai5vFntooIBbUc1WN_Zx6OjJ2w-JrUrTYWwD_gFY=.34b8ed38-86f8-444d-96ce-805da3cbaac9@github.com>
Message-ID: <XEUD3bb13nLS3gMoyTpn0IZu7QERcPfevavaVGJLnOc=.aafefba9-0331-4b50-8334-1ff2a417f6d9@github.com>

On Tue, 25 Jun 2024 15:54:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > The new patched `InetSocketAddress` is probably going to be used by all other tests in the `test/jdk/java/nio/channels/Selector/` directory.
> 
> I was under the impression that it only gets used if the test explicitly states `@compile/module=java.base java/net/InetSocketAddress.java` in its test definition and then jtreg would add the following to the test launch command:


Yes, and it runs with `--patch-module java.base=.. ` so I wouldn't expect any interference. We should be able to quick check this by looking at the command in the .jtr file.

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

PR Comment: https://git.openjdk.org/jdk/pull/19879#issuecomment-2189660670

From alanb at openjdk.org  Tue Jun 25 18:20:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Jun 2024 18:20:18 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v2]
In-Reply-To: <CNPVrTEXimQiUkqoa7pK78aFOei4nyvyolajDk8HzZc=.cc4b142e-0fbd-44b6-b52e-e1178004316f@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <NH537dhzvmUi-DelmJZUQjGAlwWoIHfB7xXf9yIEMz0=.7e803ffe-796a-469d-a6ac-b5afae24686d@github.com>
 <EpfROzvltAwz26peLXzJGUj6-JxvANLgB_imH5RhUEU=.2f42fb95-99ad-4314-b7b5-1a6aa52cefe7@github.com>
 <CNPVrTEXimQiUkqoa7pK78aFOei4nyvyolajDk8HzZc=.cc4b142e-0fbd-44b6-b52e-e1178004316f@github.com>
Message-ID: <ncxuY0U9rlMVZVW-L_-V9qWCIxnaaNmR1QTIIjU6QCU=.3a3cc4e1-d6b3-46ab-8594-8451227cdd3d@github.com>

On Tue, 25 Jun 2024 16:32:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Selector/java.base/java/net/InetSocketAddress.java line 39:
>> 
>>> 37:             return false;
>>> 38:         }
>>> 39:     };
>> 
>> A simpler way to do this is to just add a setDelay method or even a constructor that allows the delay to be specified when creating the object.  That will allow the ThredLocal to go away and make the test a bit simpler.
>
> The use of ThreadLocal was to add fine grained delays to avoid delaying all the places where InetSocketAddress gets used and increasing the test execution time. I will remove the ThreadLocal and see how big an impact it has on test durations.

Okay, whatever is easiest. My comment was really to say that a method or constructor would catch any issues at compile-time and avoid any implicit parameters. So what is easiest, this is hard test to write.

My only significant comment is about the execution time and whether we should dial it down a bit to reduce the execution time. It doesn't matter if the test doesn't reproduce every time because the test will run enough times on different systems to exercise the code path.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1653320192

From duke at openjdk.org  Tue Jun 25 20:20:17 2024
From: duke at openjdk.org (duke)
Date: Tue, 25 Jun 2024 20:20:17 GMT
Subject: Withdrawn: 8310994: Add JFR event for selection operations
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <t0BtaH8CotU90nWxbLlQcnnJX1LlRbARHc5lFdgpHxI=.c345f2f0-ff20-4c0a-9d6e-f1e714ee1c8d@github.com>

On Fri, 17 Nov 2023 16:22:55 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.org  Wed Jun 26 00:50:35 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Jun 2024 00:50:35 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v3]
In-Reply-To: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
Message-ID: <ubotMwPMm7oEUqLsOP8pLD9h0Igp_kl0K9PNdJsW4BY=.5f6a8396-4a03-493a-a858-fa43f07d3d3f@github.com>

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
> 
> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
> 
> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
> 
> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
> 
> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
> 
> Another round of tier testing with these changes is currently in progress.

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

 - merge latest master
 - move the test to a specific directory of its own
 - remove ThreadLocal and cleanup the test a bit
 - don't inject NIO_ACCESS instead patch InetSocketAddress to introduce crafted delays
 - reduce the chances of JavaNioAccess already being looked up and cached by SelectableChannel implementations
 - 8334719: add test
 - 8334719: Alan's patch for kill() in SelectableChannels

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19879/files
  - new: https://git.openjdk.org/jdk/pull/19879/files/ae041539..acbcbfe4

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

  Stats: 2520 lines in 60 files changed: 1564 ins; 799 del; 157 mod
  Patch: https://git.openjdk.org/jdk/pull/19879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19879/head:pull/19879

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

From syan at openjdk.org  Wed Jun 26 02:54:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Jun 2024 02:54:36 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v3]
In-Reply-To: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
Message-ID: <9CTI55jzSYnAQI6MXGbFxfXutc4615OL2-A1wNvzNgM=.c37e10e0-4653-46a3-9ccf-e4004ae8beb4@github.com>

> Hi all,
>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.

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

 - Merge branch 'jbs8332535' of github.com:sendaoYan/jdk-ysd into jbs8332535
 - add some entropy to the message content and discard any message that we receive whose payload doesn't match what we expect

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19314/files
  - new: https://git.openjdk.org/jdk/pull/19314/files/3f4d450e..7bce58c1

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

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

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

From syan at openjdk.org  Wed Jun 26 02:54:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Jun 2024 02:54:36 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v2]
In-Reply-To: <6bBh41jUgc6-zMA8rvWwa6EOMjRW50dQwR5d99yDeXA=.2e0ea8d0-7e53-40f6-b145-771ac679ae32@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <TQnAzFlZOagZspITuoliliNBsmAsNDixSwBDkSmB7Ts=.be11e8bc-fa75-4eae-b2df-4b55f002a252@github.com>
 <SHqreig8OALcPQkLG32k7hlAYbZ_eL52yUPFFkYdZ6E=.4227445d-a6e6-4cdd-a653-d3691203501d@github.com>
 <1_e0G5YxgY2huPkhpFwcenQfhqUfnyu4eOGXBKLvcXk=.cb113aa4-390b-42bc-8269-e7469e0353e0@github.com>
 <6bBh41jUgc6-zMA8rvWwa6EOMjRW50dQwR5d99yDeXA=.2e0ea8d0-7e53-40f6-b145-771ac679ae32@github.com>
Message-ID: <1SGpbouI8UJG2185xl5wACnnl8V1X9wKq68k3IqGr_w=.fbb905e2-c65f-4716-a9de-27ee362d56e8@github.com>

On Tue, 25 Jun 2024 17:23:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Do you mean like this:
>> 
>> -            ByteBuffer src = ByteBuffer.wrap("hello".getBytes("UTF-8"));
>> +            String str = "hello integer" + new Random().nextInt(10000);
>> +            ByteBuffer src = ByteBuffer.wrap(str.getBytes("UTF-8"));
>> 
>> And I don't known how to discard meaasge doesn't match what we expect.
>
> Yes - something like that. System.nanoTime() could work too.
> By discard, I mean compare the content of `dst` with what was put in `src` - and if it doesn't match, clear `dst` and continue to go back to select() without even looking at the sender port. You may want to adjust the timeout you pass to select the second time around.
> Rationale is: if the payloads do not match then we're just receiving some stray packet probably sent by another (test?) process, and we should ignore it. Only if the port match and the content match should we consider it a failure.

Seems that it doesn't need to adjust the timeout to select the second time around.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1653854174

From jpai at openjdk.org  Wed Jun 26 07:52:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Jun 2024 07:52:24 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v4]
In-Reply-To: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
Message-ID: <kuO2tdMKNXUsVwBMBWxpih3G_A91AE4Br828AoXEXlw=.47b5b1a3-748f-49e6-b108-9ec5c68706ef@github.com>

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
> 
> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
> 
> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
> 
> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
> 
> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
> 
> Another round of tier testing with these changes is currently in progress.

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

 - higher timeout isn't necessary for reduced iterations
 - reduce number of iterations in the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19879/files
  - new: https://git.openjdk.org/jdk/pull/19879/files/acbcbfe4..48956807

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

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

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

From jpai at openjdk.org  Wed Jun 26 07:59:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Jun 2024 07:59:09 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v4]
In-Reply-To: <kuO2tdMKNXUsVwBMBWxpih3G_A91AE4Br828AoXEXlw=.47b5b1a3-748f-49e6-b108-9ec5c68706ef@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <kuO2tdMKNXUsVwBMBWxpih3G_A91AE4Br828AoXEXlw=.47b5b1a3-748f-49e6-b108-9ec5c68706ef@github.com>
Message-ID: <ecGopT9ULa1eNCwrjfxADGx15DfQgOkmEmgrc2QdKkc=.0d3d1bb1-40a4-400b-a4c0-0f2a126aa6dc@github.com>

On Wed, 26 Jun 2024 07:52:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - higher timeout isn't necessary for reduced iterations
>  - reduce number of iterations in the test

I've now updated the PR to reduce the iterations to 10 as well as to drop the use of ThreadLocal for injecting the delay. The test continues to consistently reproduce the failures without the fix. With the fix the test continues to pass.

With the updated state of the PR, the test passes within around 6 to 7 seconds on my local macos M1. I have thus removed the large timeout from the test definition. tier testing is currently in progress.

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

PR Comment: https://git.openjdk.org/jdk/pull/19879#issuecomment-2191057724

From alanb at openjdk.org  Wed Jun 26 08:05:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jun 2024 08:05:10 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v4]
In-Reply-To: <kuO2tdMKNXUsVwBMBWxpih3G_A91AE4Br828AoXEXlw=.47b5b1a3-748f-49e6-b108-9ec5c68706ef@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <kuO2tdMKNXUsVwBMBWxpih3G_A91AE4Br828AoXEXlw=.47b5b1a3-748f-49e6-b108-9ec5c68706ef@github.com>
Message-ID: <iZxSKCLExWl5g9sJALZ1BeaSCLmbtnpZXFTfI4-ZF0E=.ac2787d9-2a2e-46ae-9248-6ef4d259bde0@github.com>

On Wed, 26 Jun 2024 07:52:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - higher timeout isn't necessary for reduced iterations
>  - reduce number of iterations in the test

Did you look at adding a method to the patched InetSocketAddress to set the delay? That would remove the need for core reflection to access the "enableDelay" field and might make it easier to maintain.

Good to see that the iteration count it reduced as I had a small concern that it might be problematic on slow machines.

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

PR Comment: https://git.openjdk.org/jdk/pull/19879#issuecomment-2191068969

From jpai at openjdk.org  Wed Jun 26 08:13:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Jun 2024 08:13:24 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v4]
In-Reply-To: <kuO2tdMKNXUsVwBMBWxpih3G_A91AE4Br828AoXEXlw=.47b5b1a3-748f-49e6-b108-9ec5c68706ef@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <kuO2tdMKNXUsVwBMBWxpih3G_A91AE4Br828AoXEXlw=.47b5b1a3-748f-49e6-b108-9ec5c68706ef@github.com>
Message-ID: <QBKp9tFfHJsyy1ca11InWSKnt1nRwQUaLho9GTZgugQ=.c6147c00-06aa-470c-b677-5efa32f2761f@github.com>

On Wed, 26 Jun 2024 07:52:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - higher timeout isn't necessary for reduced iterations
>  - reduce number of iterations in the test

Hello Alan,

> Did you look at adding a method to the patched InetSocketAddress to set the delay? That would remove the need for core reflection to access the "enableDelay" field and might make it easier to maintain.

I actually forgot that review comment. I have now updated the PR to remove the use of reflection from the test code. The test continues to fail without the source fix and passes with the source fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/19879#issuecomment-2191084643

From jpai at openjdk.org  Wed Jun 26 08:13:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Jun 2024 08:13:24 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v5]
In-Reply-To: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
Message-ID: <_WM_sjUa09fsoHhjFqn0Cx2Zo8ZVoySGMySwC6Ba78U=.562e62e3-43ee-48e4-966c-9dfdb38d7688@github.com>

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
> 
> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
> 
> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
> 
> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
> 
> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
> 
> Another round of tier testing with these changes is currently in progress.

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

  don't use reflection in the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19879/files
  - new: https://git.openjdk.org/jdk/pull/19879/files/48956807..1ca3ec6b

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

  Stats: 28 lines in 2 files changed: 8 ins; 18 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19879/head:pull/19879

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

From dfuchs at openjdk.org  Wed Jun 26 11:08:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Jun 2024 11:08:10 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v5]
In-Reply-To: <_WM_sjUa09fsoHhjFqn0Cx2Zo8ZVoySGMySwC6Ba78U=.562e62e3-43ee-48e4-966c-9dfdb38d7688@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <_WM_sjUa09fsoHhjFqn0Cx2Zo8ZVoySGMySwC6Ba78U=.562e62e3-43ee-48e4-966c-9dfdb38d7688@github.com>
Message-ID: <h-9FhPBAHcDvjYkhffKl9PM078WAd-IolS9OqHojRwU=.a6fd2d6c-af5d-47a8-aa55-7726ffc5bb13@github.com>

On Wed, 26 Jun 2024 08:13:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't use reflection in the test

test/jdk/java/nio/channels/Selector/DeferredClose/java.base/java/net/InetSocketAddress.java line 34:

> 32:     private static final long serialVersionUID = 5076001401234631237L;
> 33: 
> 34:     public static boolean enableDelay;

should it be volatile?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1654609424

From alanb at openjdk.org  Wed Jun 26 11:32:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jun 2024 11:32:10 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v5]
In-Reply-To: <h-9FhPBAHcDvjYkhffKl9PM078WAd-IolS9OqHojRwU=.a6fd2d6c-af5d-47a8-aa55-7726ffc5bb13@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <_WM_sjUa09fsoHhjFqn0Cx2Zo8ZVoySGMySwC6Ba78U=.562e62e3-43ee-48e4-966c-9dfdb38d7688@github.com>
 <h-9FhPBAHcDvjYkhffKl9PM078WAd-IolS9OqHojRwU=.a6fd2d6c-af5d-47a8-aa55-7726ffc5bb13@github.com>
Message-ID: <dl_QtEudX6V8aO-ZTbj9ohlQeBtPoiWPdud6UtqVqQw=.3006abc5-ef39-4f84-b602-b757fa3d258d@github.com>

On Wed, 26 Jun 2024 11:01:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   don't use reflection in the test
>
> test/jdk/java/nio/channels/Selector/DeferredClose/java.base/java/net/InetSocketAddress.java line 34:
> 
>> 32:     private static final long serialVersionUID = 5076001401234631237L;
>> 33: 
>> 34:     public static boolean enableDelay;
> 
> should it be volatile?

The main thing for this test is that it's easy to maintain because someone looking at the test in a few years (maybe because of a test failure) will want to understand it quickly. I assume it doesn't need to be a public static field, it could be a private instance field. I think that would remove the need for the beforeAll/afterAll as it would allow the test to just set the delay for the ISA used by the test. I don't want to water Jai's time on too many iterations on this test, I think the main thing is that it is reliable and easy to maintain.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1654640322

From jpai at openjdk.org  Wed Jun 26 11:32:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Jun 2024 11:32:10 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v5]
In-Reply-To: <dl_QtEudX6V8aO-ZTbj9ohlQeBtPoiWPdud6UtqVqQw=.3006abc5-ef39-4f84-b602-b757fa3d258d@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <_WM_sjUa09fsoHhjFqn0Cx2Zo8ZVoySGMySwC6Ba78U=.562e62e3-43ee-48e4-966c-9dfdb38d7688@github.com>
 <h-9FhPBAHcDvjYkhffKl9PM078WAd-IolS9OqHojRwU=.a6fd2d6c-af5d-47a8-aa55-7726ffc5bb13@github.com>
 <dl_QtEudX6V8aO-ZTbj9ohlQeBtPoiWPdud6UtqVqQw=.3006abc5-ef39-4f84-b602-b757fa3d258d@github.com>
Message-ID: <VLhmaYE5LsIqVCqM4TiRAtRe-1DAA2psdFcCbP0dr40=.d81ca5af-fcdc-4bd6-927a-14f00302d80b@github.com>

On Wed, 26 Jun 2024 11:28:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Selector/DeferredClose/java.base/java/net/InetSocketAddress.java line 34:
>> 
>>> 32:     private static final long serialVersionUID = 5076001401234631237L;
>>> 33: 
>>> 34:     public static boolean enableDelay;
>> 
>> should it be volatile?
>
> The main thing for this test is that it's easy to maintain because someone looking at the test in a few years (maybe because of a test failure) will want to understand it quickly. I assume it doesn't need to be a public static field, it could be a private instance field. I think that would remove the need for the beforeAll/afterAll as it would allow the test to just set the delay for the ISA used by the test. I don't want to water Jai's time on too many iterations on this test, I think the main thing is that it is reliable and easy to maintain.

Hello Daniel, I don't think it's needed. We set this to `true` (only) once in a `@BeforeAll` which gets called by one single thread. The subsequent multiple threads will only get created and launched as part of the test methods after the `@BeforeAll` has finished, so I believe they would all correctly see enableDelay as true.

After that, we only update that `enableDelay` value after all tests are done, so that too should be fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1654641761

From dfuchs at openjdk.org  Wed Jun 26 11:46:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Jun 2024 11:46:10 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v3]
In-Reply-To: <9CTI55jzSYnAQI6MXGbFxfXutc4615OL2-A1wNvzNgM=.c37e10e0-4653-46a3-9ccf-e4004ae8beb4@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <9CTI55jzSYnAQI6MXGbFxfXutc4615OL2-A1wNvzNgM=.c37e10e0-4653-46a3-9ccf-e4004ae8beb4@github.com>
Message-ID: <yFSMl843mJGXxhHpB8ancoNPg1OHCV1RLI47MiALPm0=.13a5c8b2-b4c7-4959-91bc-1106801c2776@github.com>

On Wed, 26 Jun 2024 02:54:36 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'jbs8332535' of github.com:sendaoYan/jdk-ysd into jbs8332535
>  - add some entropy to the message content and discard any message that we receive whose payload doesn't match what we expect

test/jdk/java/nio/channels/DatagramChannel/Loopback.java line 166:

> 164:                             dst.clear();
> 165:                             continue;
> 166:                         }

This is not the correct way to compare two ByteBuffers. ByteBuffer::toString only output things like position, limit, etc.. I suggest using `ByteBuffer::mismatch` instead.
You will have to `flip` src after line 146 though, since all bytes in src will have been read at that point.

https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/nio/ByteBuffer.html#mismatch(java.nio.ByteBuffer)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1654657270

From jpai at openjdk.org  Wed Jun 26 11:51:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Jun 2024 11:51:10 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v5]
In-Reply-To: <VLhmaYE5LsIqVCqM4TiRAtRe-1DAA2psdFcCbP0dr40=.d81ca5af-fcdc-4bd6-927a-14f00302d80b@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <_WM_sjUa09fsoHhjFqn0Cx2Zo8ZVoySGMySwC6Ba78U=.562e62e3-43ee-48e4-966c-9dfdb38d7688@github.com>
 <h-9FhPBAHcDvjYkhffKl9PM078WAd-IolS9OqHojRwU=.a6fd2d6c-af5d-47a8-aa55-7726ffc5bb13@github.com>
 <dl_QtEudX6V8aO-ZTbj9ohlQeBtPoiWPdud6UtqVqQw=.3006abc5-ef39-4f84-b602-b757fa3d258d@github.com>
 <VLhmaYE5LsIqVCqM4TiRAtRe-1DAA2psdFcCbP0dr40=.d81ca5af-fcdc-4bd6-927a-14f00302d80b@github.com>
Message-ID: <wcrWtmXdf5t96oKmhR9N80ZLjQgmuNvzq99YwIY6Nh8=.46ae1929-e8bb-4c39-8dc0-4f61693c50b4@github.com>

On Wed, 26 Jun 2024 11:29:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The main thing for this test is that it's easy to maintain because someone looking at the test in a few years (maybe because of a test failure) will want to understand it quickly. I assume it doesn't need to be a public static field, it could be a private instance field. I think that would remove the need for the beforeAll/afterAll as it would allow the test to just set the delay for the ISA used by the test. I don't want to water Jai's time on too many iterations on this test, I think the main thing is that it is reliable and easy to maintain.
>
> Hello Daniel, I don't think it's needed. We set this to `true` (only) once in a `@BeforeAll` which gets called by one single thread. The subsequent multiple threads will only get created and launched as part of the test methods after the `@BeforeAll` has finished, so I believe they would all correctly see enableDelay as true.
> 
> After that, we only update that `enableDelay` value after all tests are done, so that too should be fine.

> I assume it doesn't need to be a public static field, it could be a private instance field.

It should have been a private field. It's an oversight that I left it as public in a recent update. I'll fix that.

> I think that would remove the need for the beforeAll/afterAll as it would allow the test to just set the delay for the ISA used by the test.

The important detail here is that to consistently reproduce this issue both in send and receive methods of the DatagramChannelImpl, the delay has to be introduced not just in the ISA constructed by the test methods, but also in the ISA constructed by the DatagramChannelImpl implementation's decoding of native addresses to ISA. That decoding of ISA happens deep within the receive operation after it has acquired the relevant lock and that's the place where we want to slow things down so that a concurrent thread can then enter and finish close the channel which was in deferred close state.

If we wanted to reproduce the issue only for send, then constructing the delayed ISA in the test method should have been enough (because send would just call the ISA.getPort() on the ISA passed by the test method). But I also wanted to be sure that there was a way to reproduce (and thus verify the fix) for receive too (which internally calls the ISA constructor at least once upon receiving a datagram). That was the reason why I chose to have this in the beforeAll/afterAll, to keep it relatively simple.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1654663378

From jpai at openjdk.org  Wed Jun 26 11:55:43 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Jun 2024 11:55:43 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v6]
In-Reply-To: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
Message-ID: <HT78cPU712nMkoIHw2Tontv4ninY9GenHS6H9RXPYpM=.843dfa3b-45ca-420a-bcf7-7897f37d2cc3@github.com>

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
> 
> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
> 
> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
> 
> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
> 
> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
> 
> Another round of tier testing with these changes is currently in progress.

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

  enableDelay field should be private

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19879/files
  - new: https://git.openjdk.org/jdk/pull/19879/files/1ca3ec6b..d6c20385

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

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

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

From syan at openjdk.org  Wed Jun 26 12:40:41 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Jun 2024 12:40:41 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v4]
In-Reply-To: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
Message-ID: <dxBh3vyY48mHzqCJtLixEja8-XlLuPXJ-V4QXag84MQ=.4b8cd743-c66c-45fe-b542-d5a16ae98190@github.com>

> Hi all,
>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.

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

  compare ByteBuffer with mismatch()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19314/files
  - new: https://git.openjdk.org/jdk/pull/19314/files/7bce58c1..8cca8b55

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

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

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

From syan at openjdk.org  Wed Jun 26 12:40:42 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Jun 2024 12:40:42 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v3]
In-Reply-To: <yFSMl843mJGXxhHpB8ancoNPg1OHCV1RLI47MiALPm0=.13a5c8b2-b4c7-4959-91bc-1106801c2776@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <9CTI55jzSYnAQI6MXGbFxfXutc4615OL2-A1wNvzNgM=.c37e10e0-4653-46a3-9ccf-e4004ae8beb4@github.com>
 <yFSMl843mJGXxhHpB8ancoNPg1OHCV1RLI47MiALPm0=.13a5c8b2-b4c7-4959-91bc-1106801c2776@github.com>
Message-ID: <3a3Rs_iy2vJba18MQckxrLz7Rm_SFKaV2qqbxqyHfCE=.1860c1ed-239e-4019-81a6-7e7b4809aa50@github.com>

On Wed, 26 Jun 2024 11:43:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'jbs8332535' of github.com:sendaoYan/jdk-ysd into jbs8332535
>>  - add some entropy to the message content and discard any message that we receive whose payload doesn't match what we expect
>
> test/jdk/java/nio/channels/DatagramChannel/Loopback.java line 166:
> 
>> 164:                             dst.clear();
>> 165:                             continue;
>> 166:                         }
> 
> This is not the correct way to compare two ByteBuffers. ByteBuffer::toString only output things like position, limit, etc.. I suggest using `ByteBuffer::mismatch` instead.
> You will have to `flip` src after line 146 though, since all bytes in src will have been read at that point.
> 
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/nio/ByteBuffer.html#mismatch(java.nio.ByteBuffer)

Thanks for your patient guidance. The code has been modified accord to your suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1654742030

From alanb at openjdk.org  Wed Jun 26 13:35:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jun 2024 13:35:16 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v6]
In-Reply-To: <HT78cPU712nMkoIHw2Tontv4ninY9GenHS6H9RXPYpM=.843dfa3b-45ca-420a-bcf7-7897f37d2cc3@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <HT78cPU712nMkoIHw2Tontv4ninY9GenHS6H9RXPYpM=.843dfa3b-45ca-420a-bcf7-7897f37d2cc3@github.com>
Message-ID: <NOJim0ap2Y_q9EPmB1GfNGUnfUQZjfWxCOgJN-BkabI=.47938cf2-4318-4c02-8a9b-0864b3a26101@github.com>

On Wed, 26 Jun 2024 11:55:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enableDelay field should be private

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19879#pullrequestreview-2141854299

From alanb at openjdk.org  Wed Jun 26 13:35:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jun 2024 13:35:17 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v5]
In-Reply-To: <wcrWtmXdf5t96oKmhR9N80ZLjQgmuNvzq99YwIY6Nh8=.46ae1929-e8bb-4c39-8dc0-4f61693c50b4@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <_WM_sjUa09fsoHhjFqn0Cx2Zo8ZVoySGMySwC6Ba78U=.562e62e3-43ee-48e4-966c-9dfdb38d7688@github.com>
 <h-9FhPBAHcDvjYkhffKl9PM078WAd-IolS9OqHojRwU=.a6fd2d6c-af5d-47a8-aa55-7726ffc5bb13@github.com>
 <dl_QtEudX6V8aO-ZTbj9ohlQeBtPoiWPdud6UtqVqQw=.3006abc5-ef39-4f84-b602-b757fa3d258d@github.com>
 <VLhmaYE5LsIqVCqM4TiRAtRe-1DAA2psdFcCbP0dr40=.d81ca5af-fcdc-4bd6-927a-14f00302d80b@github.com>
 <wcrWtmXdf5t96oKmhR9N80ZLjQgmuNvzq99YwIY6Nh8=.46ae1929-e8bb-4c39-8dc0-4f61693c50b4@github.com>
Message-ID: <oATmAFMvEtWhE_VDHvw3spC_ODxAVZtuCUB3OWKi548=.38b041f7-7242-4682-b4af-1cb5ca0ab85c@github.com>

On Wed, 26 Jun 2024 11:48:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello Daniel, I don't think it's needed. We set this to `true` (only) once in a `@BeforeAll` which gets called by one single thread. The subsequent multiple threads will only get created and launched as part of the test methods after the `@BeforeAll` has finished, so I believe they would all correctly see enableDelay as true.
>> 
>> After that, we only update that `enableDelay` value after all tests are done, so that too should be fine.
>
>> I assume it doesn't need to be a public static field, it could be a private instance field.
> 
> It should have been a private field. It's an oversight that I left it as public in a recent update. I'll fix that.
> 
>> I think that would remove the need for the beforeAll/afterAll as it would allow the test to just set the delay for the ISA used by the test.
> 
> The important detail here is that to consistently reproduce this issue both in send and receive methods of the DatagramChannelImpl, the delay has to be introduced not just in the ISA constructed by the test methods, but also in the ISA constructed by the DatagramChannelImpl implementation's decoding of native addresses to ISA. That decoding of ISA happens deep within the receive operation after it has acquired the relevant lock and that's the place where we want to slow things down so that a concurrent thread can then enter and finish close the channel which was in deferred close state.
> 
> If we wanted to reproduce the issue only for send, then constructing the delayed ISA in the test method should have been enough (because send would just call the ISA.getPort() on the ISA passed by the test method). But I also wanted to be sure that there was a way to reproduce (and thus verify the fix) for receive too (which internally calls the ISA constructor at least once upon receiving a datagram and converting the native source address to the ISA). That was the reason why I chose to have this in the beforeAll/afterAll, to keep it relatively simple.

Okay, I think we can live with that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1654848691

From dfuchs at openjdk.org  Wed Jun 26 14:20:21 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Jun 2024 14:20:21 GMT
Subject: RFR: 8299813: java/nio/channels/DatagramChannel/Disconnect.java fails
 with jtreg test timeout due to lost datagram
Message-ID: <JmCyUr3Ah7W5Q5H5TW0s3fs_OG_MM66Macg8qhkZb-o=.30cb9e2e-f653-4664-8501-1031a80c6440@github.com>

Please find here a simple fix to solve an intermittent failure in  java/nio/channels/DatagramChannel/Disconnect.java

On some platform, the underlying system may allow two datagram sockets to bind to the same port, if one of them uses the wildcard address and the other doesn't.

What happens here is that during DC:connect, if the socket is unbound, it will get bound to the wildcard.
>From time to time, this results into binding to the same port that the `server` is using in the test.
When that happens, datagram sent to the connected server may get misrouted and may not get delivered, and the call server::receive may block forever.

This change does two things: 
  1. explicitly  bind the server to the loopback address instead of InetAddress.getLocalHost()
  2. skip the receive part of the test if the client local address obtained after connecting uses the same port than the server. 
  
This is rare, and skipping the receive part in that case does not invalidate the test.

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

Commit messages:
 - fix mistake
 - skip receive if server port and client port are identical
 - Add some more debug traces
 - 8334600

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

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

From dfuchs at openjdk.org  Wed Jun 26 14:33:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Jun 2024 14:33:11 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v6]
In-Reply-To: <HT78cPU712nMkoIHw2Tontv4ninY9GenHS6H9RXPYpM=.843dfa3b-45ca-420a-bcf7-7897f37d2cc3@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <HT78cPU712nMkoIHw2Tontv4ninY9GenHS6H9RXPYpM=.843dfa3b-45ca-420a-bcf7-7897f37d2cc3@github.com>
Message-ID: <dlipCo7oBd_G2Ui-YkUrVobr5dUfRI_v9-t6mqpneyI=.e8b598ab-0635-412f-93ef-23665af5d5e3@github.com>

On Wed, 26 Jun 2024 11:55:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enableDelay field should be private

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19879#pullrequestreview-2142067397

From dfuchs at openjdk.org  Wed Jun 26 14:33:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Jun 2024 14:33:11 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v5]
In-Reply-To: <oATmAFMvEtWhE_VDHvw3spC_ODxAVZtuCUB3OWKi548=.38b041f7-7242-4682-b4af-1cb5ca0ab85c@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <_WM_sjUa09fsoHhjFqn0Cx2Zo8ZVoySGMySwC6Ba78U=.562e62e3-43ee-48e4-966c-9dfdb38d7688@github.com>
 <h-9FhPBAHcDvjYkhffKl9PM078WAd-IolS9OqHojRwU=.a6fd2d6c-af5d-47a8-aa55-7726ffc5bb13@github.com>
 <dl_QtEudX6V8aO-ZTbj9ohlQeBtPoiWPdud6UtqVqQw=.3006abc5-ef39-4f84-b602-b757fa3d258d@github.com>
 <VLhmaYE5LsIqVCqM4TiRAtRe-1DAA2psdFcCbP0dr40=.d81ca5af-fcdc-4bd6-927a-14f00302d80b@github.com>
 <wcrWtmXdf5t96oKmhR9N80ZLjQgmuNvzq99YwIY6Nh8=.46ae1929-e8bb-4c39-8dc0-4f61693c50b4@github.com>
 <oATmAFMvEtWhE_VDHvw3spC_ODxAVZtuCUB3OWKi548=.38b041f7-7242-4682-b4af-1cb5ca0ab85c@github.com>
Message-ID: <4gpGTOr1UMMCZVVq6nMMqAYmmGHEOH8rvmV41r_Wv_g=.2c570f6c-c590-426e-8f58-fe38dfccd4ed@github.com>

On Wed, 26 Jun 2024 13:32:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> I assume it doesn't need to be a public static field, it could be a private instance field.
>> 
>> It should have been a private field. It's an oversight that I left it as public in a recent update. I'll fix that.
>> 
>>> I think that would remove the need for the beforeAll/afterAll as it would allow the test to just set the delay for the ISA used by the test.
>> 
>> The important detail here is that to consistently reproduce this issue both in send and receive methods of the DatagramChannelImpl, the delay has to be introduced not just in the ISA constructed by the test methods, but also in the ISA constructed by the DatagramChannelImpl implementation's decoding of native addresses to ISA. That decoding of ISA happens deep within the receive operation after it has acquired the relevant lock and that's the place where we want to slow things down so that a concurrent thread can then enter and finish close the channel which was in deferred close state.
>> 
>> If we wanted to reproduce the issue only for send, then constructing the delayed ISA in the test method should have been enough (because send would just call the ISA.getPort() on the ISA passed by the test method). But I also wanted to be sure that there was a way to reproduce (and thus verify the fix) for receive too (which internally calls the ISA constructor at least once upon receiving a datagram and converting the native source address to the ISA). That was the reason why I chose to have this in the beforeAll/afterAll, to keep it relatively simple.
>
> Okay, I think we can live with that.

Technically - it may be set in only one thread but it's consulted in many other threads. However there should be already enough full memory barreers around to ensure that the other threads will see the modifications, especially since these threads are started after the modification was made. So it shouldn't be an issue for the test in this form.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1654985754

From dfuchs at openjdk.org  Wed Jun 26 14:42:13 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Jun 2024 14:42:13 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v4]
In-Reply-To: <dxBh3vyY48mHzqCJtLixEja8-XlLuPXJ-V4QXag84MQ=.4b8cd743-c66c-45fe-b542-d5a16ae98190@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <dxBh3vyY48mHzqCJtLixEja8-XlLuPXJ-V4QXag84MQ=.4b8cd743-c66c-45fe-b542-d5a16ae98190@github.com>
Message-ID: <GFfFbxmD9TtaZSBAf2gIxuh8xxHNyW1eAReR7n1rAqc=.23ce17a3-e377-46a9-914f-1e6f8cdeda11@github.com>

On Wed, 26 Jun 2024 12:40:41 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   compare ByteBuffer with mismatch()

test/jdk/java/nio/channels/DatagramChannel/Loopback.java line 166:

> 164:                             System.out.println("src: " + src + "not equal to dst: " + dst);
> 165:                             dst.clear();
> 166:                             continue;

So if this happens we will go back waiting for 3 more seconds. We're not supposed to receive stray datagrams here, so I assume it might be OK to respin with 3 full seconds as this shouldn't happen too often...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1655002551

From dfuchs at openjdk.org  Wed Jun 26 14:45:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Jun 2024 14:45:10 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v4]
In-Reply-To: <dxBh3vyY48mHzqCJtLixEja8-XlLuPXJ-V4QXag84MQ=.4b8cd743-c66c-45fe-b542-d5a16ae98190@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <dxBh3vyY48mHzqCJtLixEja8-XlLuPXJ-V4QXag84MQ=.4b8cd743-c66c-45fe-b542-d5a16ae98190@github.com>
Message-ID: <0MtCAo3QaFOhDQr627cPxOY66zPlYZ0T4xsPkhXSs28=.e21f198e-cf1e-4413-af1a-fcb807b03469@github.com>

On Wed, 26 Jun 2024 12:40:41 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   compare ByteBuffer with mismatch()

Please give me some time to test the proposed changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2191890202

From syan at openjdk.org  Wed Jun 26 15:00:45 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Jun 2024 15:00:45 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v5]
In-Reply-To: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
Message-ID: <OCwMDZ0-NS2h96XN9YNnnEjWf9AKn5O5FYbuWNAKQYo=.3ad47d5e-7df2-484e-bb61-41e6bd77400e@github.com>

> Hi all,
>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.

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

  add Thread.sleep(3000) in while loop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19314/files
  - new: https://git.openjdk.org/jdk/pull/19314/files/8cca8b55..23277eff

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

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

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

From syan at openjdk.org  Wed Jun 26 15:00:45 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Jun 2024 15:00:45 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v4]
In-Reply-To: <0MtCAo3QaFOhDQr627cPxOY66zPlYZ0T4xsPkhXSs28=.e21f198e-cf1e-4413-af1a-fcb807b03469@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <dxBh3vyY48mHzqCJtLixEja8-XlLuPXJ-V4QXag84MQ=.4b8cd743-c66c-45fe-b542-d5a16ae98190@github.com>
 <0MtCAo3QaFOhDQr627cPxOY66zPlYZ0T4xsPkhXSs28=.e21f198e-cf1e-4413-af1a-fcb807b03469@github.com>
Message-ID: <-WZWMPx_GObNpC0KLTS4a51ydRKax5pNI5L5j-xQzIs=.f59031e4-baba-4254-a23a-6d51170985a0@github.com>

On Wed, 26 Jun 2024 14:43:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please give me some time to test the proposed changes.

Okey.

> test/jdk/java/nio/channels/DatagramChannel/Loopback.java line 166:
> 
>> 164:                             System.out.println("src: " + src + "not equal to dst: " + dst);
>> 165:                             dst.clear();
>> 166:                             continue;
> 
> So if this happens we will go back waiting for 3 more seconds. We're not supposed to receive stray datagrams here, so I assume it might be OK to respin with 3 full seconds as this shouldn't happen too often...

Okey, I have added Thread.sleep(3000) in while loop.

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2191928570
PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1655042668

From dfuchs at openjdk.org  Wed Jun 26 15:11:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Jun 2024 15:11:11 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v5]
In-Reply-To: <OCwMDZ0-NS2h96XN9YNnnEjWf9AKn5O5FYbuWNAKQYo=.3ad47d5e-7df2-484e-bb61-41e6bd77400e@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <OCwMDZ0-NS2h96XN9YNnnEjWf9AKn5O5FYbuWNAKQYo=.3ad47d5e-7df2-484e-bb61-41e6bd77400e@github.com>
Message-ID: <JPhhbkM5vkrHc6ONFLxDAMzNXtRxo8l5pCdqv1SBZlc=.52a1cc82-00c8-4a95-bec9-c6c4c2865f6f@github.com>

On Wed, 26 Jun 2024 15:00:45 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add Thread.sleep(3000) in while loop

test/jdk/java/nio/channels/DatagramChannel/Loopback.java line 168:

> 166:                             // We're not supposed to receive stray datagrams here,
> 167:                             // so respin with 3 full seconds as this shouldn't happen too often
> 168:                             Thread.sleep(3000);

Sorry for being unclear - please remove that Thread.sleep().

What I meant is that the `continue` statement below will lead us to calling `sel.select(3000);` again at line 155, and since we're not expecting to receive any datagram, it will block for 3 seconds again. 

Anyway - that's what the test was doing already if receiving a datagram from a socket where `senderPort != localPort` - so that's probably OK to leave it like that.

Please revert the last change - what you had before was good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1655065336

From jpai at openjdk.org  Wed Jun 26 15:25:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Jun 2024 15:25:12 GMT
Subject: RFR: 8334719: (se) Deferred close of SelectableChannel may result
 in a Selector doing the final close before concurrent I/O on channel
 has completed [v6]
In-Reply-To: <HT78cPU712nMkoIHw2Tontv4ninY9GenHS6H9RXPYpM=.843dfa3b-45ca-420a-bcf7-7897f37d2cc3@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
 <HT78cPU712nMkoIHw2Tontv4ninY9GenHS6H9RXPYpM=.843dfa3b-45ca-420a-bcf7-7897f37d2cc3@github.com>
Message-ID: <sOxXGcALJLGbbyqVcYSEsQWUEGxit_f05I6X7HJhDQQ=.e3665318-82c8-42ad-8719-05e0d0c799a2@github.com>

On Wed, 26 Jun 2024 11:55:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enableDelay field should be private

Thank you Alan and Daniel for the extensive feedback and suggestions. I've tier testing currently in progress in the CI and once those complete, I'll integrate this tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/19879#issuecomment-2191983937

From syan at openjdk.org  Wed Jun 26 15:46:31 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Jun 2024 15:46:31 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v6]
In-Reply-To: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
Message-ID: <ifl-eXj_r-LCtmyfQCffB5-bTmfnzlgQ0hbqU2QvD-E=.50859b35-5c0b-4b01-a8ce-861a458134c4@github.com>

> Hi all,
>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.

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

  delete Thread.sleep and InterruptedException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19314/files
  - new: https://git.openjdk.org/jdk/pull/19314/files/23277eff..7b06dcf1

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

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

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

From syan at openjdk.org  Wed Jun 26 15:46:32 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Jun 2024 15:46:32 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v5]
In-Reply-To: <JPhhbkM5vkrHc6ONFLxDAMzNXtRxo8l5pCdqv1SBZlc=.52a1cc82-00c8-4a95-bec9-c6c4c2865f6f@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <OCwMDZ0-NS2h96XN9YNnnEjWf9AKn5O5FYbuWNAKQYo=.3ad47d5e-7df2-484e-bb61-41e6bd77400e@github.com>
 <JPhhbkM5vkrHc6ONFLxDAMzNXtRxo8l5pCdqv1SBZlc=.52a1cc82-00c8-4a95-bec9-c6c4c2865f6f@github.com>
Message-ID: <ysCNFhF4mlGDKo9sLvR01WdxBQ7K1HREF4QttJgfJnk=.bb0e9faa-115d-4d44-a3d8-5723faf7e18d@github.com>

On Wed, 26 Jun 2024 15:08:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add Thread.sleep(3000) in while loop
>
> test/jdk/java/nio/channels/DatagramChannel/Loopback.java line 168:
> 
>> 166:                             // We're not supposed to receive stray datagrams here,
>> 167:                             // so respin with 3 full seconds as this shouldn't happen too often
>> 168:                             Thread.sleep(3000);
> 
> Sorry for being unclear - please remove that Thread.sleep().
> 
> What I meant is that the `continue` statement below will lead us to calling `sel.select(3000);` again at line 155, and since we're not expecting to receive any datagram, it will block for 3 seconds again. 
> 
> Anyway - that's what the test was doing already if receiving a datagram from a socket where `senderPort != localPort` - so that's probably OK to leave it like that.
> 
> Please revert the last change - what you had before was good.

Sorry for the misunderstand, Thread.sleep and InterruptedException has been deleted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1655118184

From jpai at openjdk.org  Thu Jun 27 04:41:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Jun 2024 04:41:16 GMT
Subject: Integrated: 8334719: (se) Deferred close of SelectableChannel may
 result in a Selector doing the final close before concurrent I/O on channel
 has completed
In-Reply-To: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
References: <Wx5rb6e-2pGPO7E7wBukLDe7It8awh1TIBNGGSO86ik=.e023e71d-8b41-4308-9485-e555caa57a18@github.com>
Message-ID: <tYodEn89_A_JYHrbwjtvvIuwW62Tg-HtxmfsAY2uWMI=.b7b3c583-8325-4ba1-9b4e-86fb9cb64a14@github.com>

On Tue, 25 Jun 2024 11:31:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
> 
> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
> 
> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
> 
> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
> 
> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
> 
> Another round of tier testing with these changes is currently in progress.

This pull request has now been integrated.

Changeset: 9bb675f8
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9bb675f89dd1eeec423ca96cb3f96d29f5de477c
Stats:     705 lines in 7 files changed: 705 ins; 0 del; 0 mod

8334719: (se) Deferred close of SelectableChannel may result in a Selector doing the final close before concurrent I/O on channel has completed

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: alanb, dfuchs

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

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

From clanger at openjdk.org  Thu Jun 27 04:42:14 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 27 Jun 2024 04:42:14 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v6]
In-Reply-To: <ifl-eXj_r-LCtmyfQCffB5-bTmfnzlgQ0hbqU2QvD-E=.50859b35-5c0b-4b01-a8ce-861a458134c4@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <ifl-eXj_r-LCtmyfQCffB5-bTmfnzlgQ0hbqU2QvD-E=.50859b35-5c0b-4b01-a8ce-861a458134c4@github.com>
Message-ID: <AOUp_9ExPVHbC_KnHB3ObA4qs7-Mkv2M_kF9maT36AY=.026787db-9681-4072-adb8-58b7d5f68be0@github.com>

On Wed, 26 Jun 2024 15:46:31 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete Thread.sleep and InterruptedException

Hi, can you maybe refrain from adding the intermittent keyword to the test? In our test setup at SAP this would mean that the test is not run any longer.

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2193681752

From jpai at openjdk.org  Thu Jun 27 04:50:37 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Jun 2024 04:50:37 GMT
Subject: [jdk23] RFR: 8334719: (se) Deferred close of SelectableChannel may
 result in a Selector doing the final close before concurrent I/O on channel
 has completed
Message-ID: <qHPJD9RLoxe_QUDDQj-ihtKv-Rc6KWA9TtatkEG8Cwk=.c2979dab-964e-4ac4-98b3-942c1c35822c@github.com>

I would like to backport this bug fix for a P3 issue into jdk23 branch. The backport is clean and the original fix was reviewed in mainline https://github.com/openjdk/jdk/pull/19879.

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

Commit messages:
 - Backport 9bb675f89dd1eeec423ca96cb3f96d29f5de477c

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

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

From syan at openjdk.org  Thu Jun 27 06:47:11 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 27 Jun 2024 06:47:11 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v6]
In-Reply-To: <AOUp_9ExPVHbC_KnHB3ObA4qs7-Mkv2M_kF9maT36AY=.026787db-9681-4072-adb8-58b7d5f68be0@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <ifl-eXj_r-LCtmyfQCffB5-bTmfnzlgQ0hbqU2QvD-E=.50859b35-5c0b-4b01-a8ce-861a458134c4@github.com>
 <AOUp_9ExPVHbC_KnHB3ObA4qs7-Mkv2M_kF9maT36AY=.026787db-9681-4072-adb8-58b7d5f68be0@github.com>
Message-ID: <G_YubGgHYuhBEc4zBSQi0bCXf9giMAg86_uIdM7erU8=.797c3c18-1b7d-41e9-9e7e-ec7cc7a7d24e@github.com>

On Thu, 27 Jun 2024 04:39:10 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi, can you maybe refrain from adding the intermittent keyword to the test? In our test setup at SAP this would mean that the test is not run any longer.

@dfuch I run this test after the this patch 20k times and all passed, maybe the `@key intermittent` tag not longer needed

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2193920288

From dfuchs at openjdk.org  Thu Jun 27 06:49:20 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Jun 2024 06:49:20 GMT
Subject: RFR: 8277949: (dc) java/nio/channels/DatagramChannel/AdaptorBasic.java
 failed in timeout
Message-ID: <wnVuuO0JfhoVDVvQK43pi0lR1tnZkwV9j9UYXWjMOVw=.49e2080e-a915-46b3-bba4-ac554ffadced@github.com>

On macOS, when binding a datagram socket to the wildcard address with port 0, or when connecting an unbound socket (which ends up binding the socket to the wildacrd with port 0 first), the system may assign a port which is already used by another socket for a different local address. When that happens, a datagram may get misrouted which explains the intermittent failures where the test is blocked in receive().

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

Commit messages:
 - Avoid using wildcard address on macOS if possible
 - Minor doc fix
 - 8277949

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

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

From dfuchs at openjdk.org  Thu Jun 27 07:21:14 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Jun 2024 07:21:14 GMT
Subject: RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java
 as intermittent [v4]
In-Reply-To: <0MtCAo3QaFOhDQr627cPxOY66zPlYZ0T4xsPkhXSs28=.e21f198e-cf1e-4413-af1a-fcb807b03469@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <dxBh3vyY48mHzqCJtLixEja8-XlLuPXJ-V4QXag84MQ=.4b8cd743-c66c-45fe-b542-d5a16ae98190@github.com>
 <0MtCAo3QaFOhDQr627cPxOY66zPlYZ0T4xsPkhXSs28=.e21f198e-cf1e-4413-af1a-fcb807b03469@github.com>
Message-ID: <oGY9T1aOFMpi4fsix_STzlIuZcXSfa4wuFPGRsFHvoI=.d05a3f0a-db7d-4b4a-bbd5-4e6547d221d9@github.com>

On Wed, 26 Jun 2024 14:43:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   compare ByteBuffer with mismatch()
>
> Please give me some time to test the proposed changes.

> @dfuch I run this test after the this patch 20k times and all passed, maybe the @key intermittent tag not longer needed

Fine to remove the intermitent label then. We will need to change the title of the PR and the JBS issue to reflect what this change is about though.

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2193970973

From syan at openjdk.org  Thu Jun 27 07:28:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 27 Jun 2024 07:28:39 GMT
Subject: RFR: 8332535: Discard any message not expect in Loopback.java [v7]
In-Reply-To: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
Message-ID: <tY8LAiAXy2M87yeO337FS2YNp1T7GMmrzB0RfFD0gpI=.1572a05f-d456-40d9-b894-10f808c75a95@github.com>

> Hi all,
>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.

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

  delete @key intermittent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19314/files
  - new: https://git.openjdk.org/jdk/pull/19314/files/7b06dcf1..ad8e1de0

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

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

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

From dfuchs at openjdk.org  Thu Jun 27 10:50:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Jun 2024 10:50:11 GMT
Subject: RFR: 8332535: Discard any message not expected in Loopback.java
 [v7]
In-Reply-To: <tY8LAiAXy2M87yeO337FS2YNp1T7GMmrzB0RfFD0gpI=.1572a05f-d456-40d9-b894-10f808c75a95@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <tY8LAiAXy2M87yeO337FS2YNp1T7GMmrzB0RfFD0gpI=.1572a05f-d456-40d9-b894-10f808c75a95@github.com>
Message-ID: <mijdNG-XaSFeNn8FLakTat2eRzjdUUrzrZ9dyFcDxMk=.fb36f4b4-a34a-4a2d-a7d2-529f43f654a0@github.com>

On Thu, 27 Jun 2024 07:28:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. This PR mark this test intermittent, and print more messages to investigate the intermittent failure. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete @key intermittent

Actually - maybe we should use [JDK-8269657](https://bugs.openjdk.org/browse/JDK-8269657) for this change, since it fixes the test failure.
FWIW - I have launched some repeated tests in our CI - so far this looks promising :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2194365612

From syan at openjdk.org  Thu Jun 27 11:53:12 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 27 Jun 2024 11:53:12 GMT
Subject: RFR: 8332535: Discard any message not expected in Loopback.java
 [v7]
In-Reply-To: <mijdNG-XaSFeNn8FLakTat2eRzjdUUrzrZ9dyFcDxMk=.fb36f4b4-a34a-4a2d-a7d2-529f43f654a0@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <tY8LAiAXy2M87yeO337FS2YNp1T7GMmrzB0RfFD0gpI=.1572a05f-d456-40d9-b894-10f808c75a95@github.com>
 <mijdNG-XaSFeNn8FLakTat2eRzjdUUrzrZ9dyFcDxMk=.fb36f4b4-a34a-4a2d-a7d2-529f43f654a0@github.com>
Message-ID: <ZXsKTZfZP-c_8PhWP_4O0ds3dxSXAoDkgY_nwVlsw-A=.04260cfc-fd0d-4a0f-977f-8f8773bacc7c@github.com>

On Thu, 27 Jun 2024 10:46:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Actually - maybe we should use [JDK-8269657](https://bugs.openjdk.org/browse/JDK-8269657) for this change, since it fixes the test failure. You can grab it from @Michael-Mc-Mahon, I don't think he will mind :-) Otherwise we'll just close it as a duplicate of JDK-8332535 - but it is strange to see an issue closed as a duplicate of its subtask.
> 
> FWIW - I have launched some repeated tests in our CI - so far this looks promising :-)

Okey.

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2194473810

From alanb at openjdk.org  Fri Jun 28 06:39:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Jun 2024 06:39:21 GMT
Subject: [jdk23] RFR: 8334719: (se) Deferred close of SelectableChannel may
 result in a Selector doing the final close before concurrent I/O on channel
 has completed
In-Reply-To: <qHPJD9RLoxe_QUDDQj-ihtKv-Rc6KWA9TtatkEG8Cwk=.c2979dab-964e-4ac4-98b3-942c1c35822c@github.com>
References: <qHPJD9RLoxe_QUDDQj-ihtKv-Rc6KWA9TtatkEG8Cwk=.c2979dab-964e-4ac4-98b3-942c1c35822c@github.com>
Message-ID: <CQa7eB5ulLDQQQEHwXFIDq8oTK6mKpBtnnNiu1Bbh9g=.8622d403-b823-435e-9e18-e715c63eca9a@github.com>

On Thu, 27 Jun 2024 04:46:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I would like to backport this bug fix for a P3 issue into jdk23 branch. The backport is clean and the original fix was reviewed in mainline https://github.com/openjdk/jdk/pull/19879.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19920#pullrequestreview-2147172272

From dfuchs at openjdk.org  Fri Jun 28 08:42:21 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Jun 2024 08:42:21 GMT
Subject: RFR: 8269657: Test Loopback.java failed: Unexpected message [v7]
In-Reply-To: <tY8LAiAXy2M87yeO337FS2YNp1T7GMmrzB0RfFD0gpI=.1572a05f-d456-40d9-b894-10f808c75a95@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <tY8LAiAXy2M87yeO337FS2YNp1T7GMmrzB0RfFD0gpI=.1572a05f-d456-40d9-b894-10f808c75a95@github.com>
Message-ID: <3SY9e8jFGEd0YAAQlgr4gdNDoaGSExVFix87JTFZ2Ww=.6ce5bfe1-e588-4858-9881-dccfcdfde3d3@github.com>

On Thu, 27 Jun 2024 07:28:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. 
>> This PR mark add some entropy(System.nanoTime) to the message content, and if the payloads doesn't match then ignore it, because payloads probably receiving some stray packet sent by another process. Only if the port unmatch and the content match we consider it a failure.
>> The change has been verified locally, I have runed the test after the this patch 20k times and all passed. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete @key intermittent

test/jdk/java/nio/channels/DatagramChannel/Loopback.java line 25:

> 23: 
> 24: /* @test
> 25:  * @bug 8236184 8332535

You can remove 8332535 here. We usually only put bug ids here if there are source code changes that the test is testing. If the bug being fixed is in the test itself, we don't list the bug id here.
Suggestion:

 * @bug 8236184


My tests were positive. I will approve after you make this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1658361614

From syan at openjdk.org  Fri Jun 28 08:51:35 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 28 Jun 2024 08:51:35 GMT
Subject: RFR: 8269657: Test Loopback.java failed: Unexpected message [v8]
In-Reply-To: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
Message-ID: <YH3o6sWrmxYCO5rNvw6MUav2Dp674K2MkbXBxRpZhaI=.b8d9abfc-4e0a-4fce-9f4d-f6c56a9ef4b7@github.com>

> Hi all,
>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. 
> This PR mark add some entropy(System.nanoTime) to the message content, and if the payloads doesn't match then ignore it, because payloads probably receiving some stray packet sent by another process. Only if the port unmatch and the content match we consider it a failure.
> The change has been verified locally, I have runed the test after the this patch 20k times and all passed. Only change the testcase, no risk.

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

  delete bud id 8332535

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19314/files
  - new: https://git.openjdk.org/jdk/pull/19314/files/ad8e1de0..fb5bdc2b

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

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

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

From syan at openjdk.org  Fri Jun 28 08:51:35 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 28 Jun 2024 08:51:35 GMT
Subject: RFR: 8269657: Test Loopback.java failed: Unexpected message [v7]
In-Reply-To: <3SY9e8jFGEd0YAAQlgr4gdNDoaGSExVFix87JTFZ2Ww=.6ce5bfe1-e588-4858-9881-dccfcdfde3d3@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <tY8LAiAXy2M87yeO337FS2YNp1T7GMmrzB0RfFD0gpI=.1572a05f-d456-40d9-b894-10f808c75a95@github.com>
 <3SY9e8jFGEd0YAAQlgr4gdNDoaGSExVFix87JTFZ2Ww=.6ce5bfe1-e588-4858-9881-dccfcdfde3d3@github.com>
Message-ID: <KBMh-Sxbf7qoT3LQlwdnBZFixLPPpgiDoEgUlyQ0Cks=.e7b84359-278b-47d8-9c8e-70a7f6adb674@github.com>

On Fri, 28 Jun 2024 08:39:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete @key intermittent
>
> test/jdk/java/nio/channels/DatagramChannel/Loopback.java line 25:
> 
>> 23: 
>> 24: /* @test
>> 25:  * @bug 8236184 8332535
> 
> You can remove 8332535 here. We usually only put bug ids here if there are source code changes that the test is testing. If the bug being fixed is in the test itself, we don't list the bug id here.
> Suggestion:
> 
>  * @bug 8236184
> 
> 
> My tests were positive. I will approve after you make this change.

Okey.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19314#discussion_r1658370649

From dfuchs at openjdk.org  Fri Jun 28 09:06:27 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Jun 2024 09:06:27 GMT
Subject: RFR: 8269657: Test Loopback.java failed: Unexpected message [v8]
In-Reply-To: <YH3o6sWrmxYCO5rNvw6MUav2Dp674K2MkbXBxRpZhaI=.b8d9abfc-4e0a-4fce-9f4d-f6c56a9ef4b7@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <YH3o6sWrmxYCO5rNvw6MUav2Dp674K2MkbXBxRpZhaI=.b8d9abfc-4e0a-4fce-9f4d-f6c56a9ef4b7@github.com>
Message-ID: <Jda6ApPCvb5pVGZ71Rv63N-1atFKQH89ql6B9IgjIsY=.f8ed0779-34b9-48cc-9b4e-47b4bfb77dd9@github.com>

On Fri, 28 Jun 2024 08:51:35 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. 
>> This PR mark add some entropy(System.nanoTime) to the message content, and if the payloads doesn't match then ignore it, because payloads probably receiving some stray packet sent by another process. Only if the port unmatch and the content match we consider it a failure.
>> The change has been verified locally, I have runed the test after the this patch 20k times and all passed. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete bud id 8332535

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19314#pullrequestreview-2147433925

From jpai at openjdk.org  Fri Jun 28 09:16:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Jun 2024 09:16:21 GMT
Subject: RFR: 8277949: (dc)
 java/nio/channels/DatagramChannel/AdaptorBasic.java failed in timeout
In-Reply-To: <wnVuuO0JfhoVDVvQK43pi0lR1tnZkwV9j9UYXWjMOVw=.49e2080e-a915-46b3-bba4-ac554ffadced@github.com>
References: <wnVuuO0JfhoVDVvQK43pi0lR1tnZkwV9j9UYXWjMOVw=.49e2080e-a915-46b3-bba4-ac554ffadced@github.com>
Message-ID: <3KBKFZ3DPNKehdDUvHW4MkVZ4dSeSxY3Kk2jPbAlyXU=.c9304e0c-ac31-493a-914a-0d6ae63949fa@github.com>

On Thu, 27 Jun 2024 06:44:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> On macOS, when binding a datagram socket to the wildcard address with port 0, or when connecting an unbound socket (which ends up binding the socket to the wildacrd with port 0 first), the system may assign a port which is already used by another socket for a different local address. When that happens, a datagram may get misrouted which explains the intermittent failures where the test is blocked in receive().

The changes look OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19922#pullrequestreview-2147452497

From syan at openjdk.org  Fri Jun 28 09:18:20 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 28 Jun 2024 09:18:20 GMT
Subject: RFR: 8269657: Test java/nio/channels/DatagramChannel/Loopback.java
 failed: Unexpected message [v8]
In-Reply-To: <YH3o6sWrmxYCO5rNvw6MUav2Dp674K2MkbXBxRpZhaI=.b8d9abfc-4e0a-4fce-9f4d-f6c56a9ef4b7@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <YH3o6sWrmxYCO5rNvw6MUav2Dp674K2MkbXBxRpZhaI=.b8d9abfc-4e0a-4fce-9f4d-f6c56a9ef4b7@github.com>
Message-ID: <DlSQgtbtHbLr7_r8cSPpaCHCgcd7m-eRW1c03shTO9w=.4299d750-9ffd-47b0-ad3a-d651dff167de@github.com>

On Fri, 28 Jun 2024 08:51:35 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. 
>> This PR mark add some entropy(System.nanoTime) to the message content, and if the payloads doesn't match then ignore it, because payloads probably receiving some stray packet sent by another process. Only if the port unmatch and the content match we consider it a failure.
>> The change has been verified locally, I have runed the test after the this patch 20k times and all passed. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete bud id 8332535

Thanks for the patient guidance and review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2196474768

From duke at openjdk.org  Fri Jun 28 09:18:20 2024
From: duke at openjdk.org (duke)
Date: Fri, 28 Jun 2024 09:18:20 GMT
Subject: RFR: 8269657: Test java/nio/channels/DatagramChannel/Loopback.java
 failed: Unexpected message [v8]
In-Reply-To: <YH3o6sWrmxYCO5rNvw6MUav2Dp674K2MkbXBxRpZhaI=.b8d9abfc-4e0a-4fce-9f4d-f6c56a9ef4b7@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <YH3o6sWrmxYCO5rNvw6MUav2Dp674K2MkbXBxRpZhaI=.b8d9abfc-4e0a-4fce-9f4d-f6c56a9ef4b7@github.com>
Message-ID: <kMOEgaeDYfSoCXdOWntiS3K5AlnJ6LIDjt3w1GTOMtY=.02feedaa-eeb5-4e29-b02e-17f724d0ed03@github.com>

On Fri, 28 Jun 2024 08:51:35 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. 
>> This PR mark add some entropy(System.nanoTime) to the message content, and if the payloads doesn't match then ignore it, because payloads probably receiving some stray packet sent by another process. Only if the port unmatch and the content match we consider it a failure.
>> The change has been verified locally, I have runed the test after the this patch 20k times and all passed. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete bud id 8332535

@sendaoYan 
Your change (at version fb5bdc2b22a6c9b61f94c978873a21d4f8590452) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2196476620

From dfuchs at openjdk.org  Fri Jun 28 09:27:23 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Jun 2024 09:27:23 GMT
Subject: RFR: 8269657: Test java/nio/channels/DatagramChannel/Loopback.java
 failed: Unexpected message [v8]
In-Reply-To: <DlSQgtbtHbLr7_r8cSPpaCHCgcd7m-eRW1c03shTO9w=.4299d750-9ffd-47b0-ad3a-d651dff167de@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <YH3o6sWrmxYCO5rNvw6MUav2Dp674K2MkbXBxRpZhaI=.b8d9abfc-4e0a-4fce-9f4d-f6c56a9ef4b7@github.com>
 <DlSQgtbtHbLr7_r8cSPpaCHCgcd7m-eRW1c03shTO9w=.4299d750-9ffd-47b0-ad3a-d651dff167de@github.com>
Message-ID: <EK8sPCBIdvO6LozRRMDua4SV7uqK6rVMom2OTmK3sYA=.bb725a04-17b2-4a8e-a695-5d5a665107d2@github.com>

On Fri, 28 Jun 2024 09:14:10 GMT, SendaoYan <syan at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete bud id 8332535
>
> Thanks for the patient guidance and review.

Hi @sendaoYan - thanks for integrating all the feedbcak. I can sponsor this change - unless you already have a sponsor?

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2196492667

From dfuchs at openjdk.org  Fri Jun 28 09:29:20 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Jun 2024 09:29:20 GMT
Subject: RFR: 8277949: (dc)
 java/nio/channels/DatagramChannel/AdaptorBasic.java failed in timeout
In-Reply-To: <3KBKFZ3DPNKehdDUvHW4MkVZ4dSeSxY3Kk2jPbAlyXU=.c9304e0c-ac31-493a-914a-0d6ae63949fa@github.com>
References: <wnVuuO0JfhoVDVvQK43pi0lR1tnZkwV9j9UYXWjMOVw=.49e2080e-a915-46b3-bba4-ac554ffadced@github.com>
 <3KBKFZ3DPNKehdDUvHW4MkVZ4dSeSxY3Kk2jPbAlyXU=.c9304e0c-ac31-493a-914a-0d6ae63949fa@github.com>
Message-ID: <9B6goG2xnPGTVXvizVW3Hnm9rSjB1_hHyXpODCvp_KY=.865689c2-2455-47dc-9994-c3def85348b1@github.com>

On Fri, 28 Jun 2024 09:13:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> On macOS, when binding a datagram socket to the wildcard address with port 0, or when connecting an unbound socket (which ends up binding the socket to the wildacrd with port 0 first), the system may assign a port which is already used by another socket for a different local address. When that happens, a datagram may get misrouted which explains the intermittent failures where the test is blocked in receive().
>
> The changes look OK to me.

Thank you @jaikiran. Unless I receive further comments I'll integrate shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/19922#issuecomment-2196495829

From syan at openjdk.org  Fri Jun 28 09:31:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 28 Jun 2024 09:31:23 GMT
Subject: RFR: 8269657: Test java/nio/channels/DatagramChannel/Loopback.java
 failed: Unexpected message [v8]
In-Reply-To: <DlSQgtbtHbLr7_r8cSPpaCHCgcd7m-eRW1c03shTO9w=.4299d750-9ffd-47b0-ad3a-d651dff167de@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <YH3o6sWrmxYCO5rNvw6MUav2Dp674K2MkbXBxRpZhaI=.b8d9abfc-4e0a-4fce-9f4d-f6c56a9ef4b7@github.com>
 <DlSQgtbtHbLr7_r8cSPpaCHCgcd7m-eRW1c03shTO9w=.4299d750-9ffd-47b0-ad3a-d651dff167de@github.com>
Message-ID: <GjryMOq6hCsFlDIbdPbx7j0G9NwkKh9b2tKdAXMiAxQ=.ad01c270-d7cc-4881-b0df-c7e403a14d20@github.com>

On Fri, 28 Jun 2024 09:14:10 GMT, SendaoYan <syan at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete bud id 8332535
>
> Thanks for the patient guidance and review.

> Hi @sendaoYan - thanks for integrating all the feedbcak. I can sponsor this change - unless you already have a sponsor?

No, I need your sponsor, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2196498330

From syan at openjdk.org  Fri Jun 28 09:41:26 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 28 Jun 2024 09:41:26 GMT
Subject: Integrated: 8269657: Test
 java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message
In-Reply-To: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
Message-ID: <FhyqhL0ICpW8jD9YaaCnJGeMdZlMBj-b4aQXE-YzQjo=.7994aca1-e046-4143-abf7-58885b79dbea@github.com>

On Mon, 20 May 2024 15:39:52 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. 
> This PR mark add some entropy(System.nanoTime) to the message content, and if the payloads doesn't match then ignore it, because payloads probably receiving some stray packet sent by another process. Only if the port unmatch and the content match we consider it a failure.
> The change has been verified locally, I have runed the test after the this patch 20k times and all passed. Only change the testcase, no risk.

This pull request has now been integrated.

Changeset: c798316b
Author:    SendaoYan <syan at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c798316bc4cb33fd902f926030d8a0b6870d661a
Stats:     11 lines in 1 file changed: 8 ins; 0 del; 3 mod

8269657: Test java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message

Reviewed-by: dfuchs

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

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

From syan at openjdk.org  Fri Jun 28 09:47:26 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 28 Jun 2024 09:47:26 GMT
Subject: RFR: 8269657: Test java/nio/channels/DatagramChannel/Loopback.java
 failed: Unexpected message [v8]
In-Reply-To: <YH3o6sWrmxYCO5rNvw6MUav2Dp674K2MkbXBxRpZhaI=.b8d9abfc-4e0a-4fce-9f4d-f6c56a9ef4b7@github.com>
References: <aO2DXZTlwZuhSPMtYSej6GoB7iZDZF0xTj38rX1zgsE=.8e577353-17cc-44de-b2c7-a68ec632f119@github.com>
 <YH3o6sWrmxYCO5rNvw6MUav2Dp674K2MkbXBxRpZhaI=.b8d9abfc-4e0a-4fce-9f4d-f6c56a9ef4b7@github.com>
Message-ID: <Z63WGkxfzz57nTzIGT3mbk3T2u6kvQgjoFkwbD49_HE=.9ec2f147-8f4c-4474-8ec8-b82a6aec3b2b@github.com>

On Fri, 28 Jun 2024 08:51:35 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   The test `test/jdk/java/nio/channels/DatagramChannel/Loopback.java` intermittent fail, the failure probability is about 2/1000. 
>> This PR mark add some entropy(System.nanoTime) to the message content, and if the payloads doesn't match then ignore it, because payloads probably receiving some stray packet sent by another process. Only if the port unmatch and the content match we consider it a failure.
>> The change has been verified locally, I have runed the test after the this patch 20k times and all passed. Only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete bud id 8332535

Thanks for the sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2196525090

From aefimov at openjdk.org  Fri Jun 28 09:53:22 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 28 Jun 2024 09:53:22 GMT
Subject: RFR: 8299813: java/nio/channels/DatagramChannel/Disconnect.java
 fails with jtreg test timeout due to lost datagram
In-Reply-To: <JmCyUr3Ah7W5Q5H5TW0s3fs_OG_MM66Macg8qhkZb-o=.30cb9e2e-f653-4664-8501-1031a80c6440@github.com>
References: <JmCyUr3Ah7W5Q5H5TW0s3fs_OG_MM66Macg8qhkZb-o=.30cb9e2e-f653-4664-8501-1031a80c6440@github.com>
Message-ID: <HNchyNFtC0aodL7eKALL0pO3Hkwn2sRBVUcIaJSQ2yA=.ed79f90c-a595-4f63-9a27-c0ceec37282b@github.com>

On Wed, 26 Jun 2024 14:15:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a simple fix to solve an intermittent failure in  java/nio/channels/DatagramChannel/Disconnect.java
> 
> On some platform, the underlying system may allow two datagram sockets to bind to the same port, if one of them uses the wildcard address and the other doesn't.
> 
> What happens here is that during DC:connect, if the socket is unbound, it will get bound to the wildcard.
> From time to time, this results into binding to the same port that the `server` is using in the test.
> When that happens, datagram sent to the connected server may get misrouted and may not get delivered, and the call server::receive may block forever.
> 
> This change does two things: 
>   1. explicitly  bind the server to the loopback address instead of InetAddress.getLocalHost()
>   2. skip the receive part of the test if the client local address obtained after connecting uses the same port than the server. 
>   
> This is rare, and skipping the receive part in that case does not invalidate the test.

The changes look good to me.

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

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19908#pullrequestreview-2147524606

From syan at openjdk.org  Fri Jun 28 09:53:43 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 28 Jun 2024 09:53:43 GMT
Subject: [jdk23] RFR: 8269657: Test
 java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message
Message-ID: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>

Hi all,

This pull request contains a backport of commit [c798316b](https://github.com/openjdk/jdk/commit/c798316bc4cb33fd902f926030d8a0b6870d661a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by SendaoYan on 28 Jun 2024 and was reviewed by Daniel Fuchs.

Thanks!

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

Commit messages:
 - Backport c798316bc4cb33fd902f926030d8a0b6870d661a

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

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

From dfuchs at openjdk.org  Fri Jun 28 10:20:18 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Jun 2024 10:20:18 GMT
Subject: RFR: 8299813: java/nio/channels/DatagramChannel/Disconnect.java
 fails with jtreg test timeout due to lost datagram
In-Reply-To: <HNchyNFtC0aodL7eKALL0pO3Hkwn2sRBVUcIaJSQ2yA=.ed79f90c-a595-4f63-9a27-c0ceec37282b@github.com>
References: <JmCyUr3Ah7W5Q5H5TW0s3fs_OG_MM66Macg8qhkZb-o=.30cb9e2e-f653-4664-8501-1031a80c6440@github.com>
 <HNchyNFtC0aodL7eKALL0pO3Hkwn2sRBVUcIaJSQ2yA=.ed79f90c-a595-4f63-9a27-c0ceec37282b@github.com>
Message-ID: <DOc4i16zsa3byM3ZRe994n0vlCFiwKC2rV6WUqlrUUg=.dede2587-3d3a-4c64-92fe-565ba5b25611@github.com>

On Fri, 28 Jun 2024 09:50:50 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Please find here a simple fix to solve an intermittent failure in  java/nio/channels/DatagramChannel/Disconnect.java
>> 
>> On some platform, the underlying system may allow two datagram sockets to bind to the same port, if one of them uses the wildcard address and the other doesn't.
>> 
>> What happens here is that during DC:connect, if the socket is unbound, it will get bound to the wildcard.
>> From time to time, this results into binding to the same port that the `server` is using in the test.
>> When that happens, datagram sent to the connected server may get misrouted and may not get delivered, and the call server::receive may block forever.
>> 
>> This change does two things: 
>>   1. explicitly  bind the server to the loopback address instead of InetAddress.getLocalHost()
>>   2. skip the receive part of the test if the client local address obtained after connecting uses the same port than the server. 
>>   
>> This is rare, and skipping the receive part in that case does not invalidate the test.
>
> The changes look good to me.

Thanks @AlekseiEfimov ! If I don't receive further feedback I will integrate shortly

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

PR Comment: https://git.openjdk.org/jdk/pull/19908#issuecomment-2196577027

From dfuchs at openjdk.org  Fri Jun 28 11:06:31 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Jun 2024 11:06:31 GMT
Subject: Integrated: 8277949: (dc)
 java/nio/channels/DatagramChannel/AdaptorBasic.java failed in timeout
In-Reply-To: <wnVuuO0JfhoVDVvQK43pi0lR1tnZkwV9j9UYXWjMOVw=.49e2080e-a915-46b3-bba4-ac554ffadced@github.com>
References: <wnVuuO0JfhoVDVvQK43pi0lR1tnZkwV9j9UYXWjMOVw=.49e2080e-a915-46b3-bba4-ac554ffadced@github.com>
Message-ID: <83zwJF7Dwzrkd0JaP8xyx_SqmP0f8pw-ZYHrp8y9aoE=.0f2af75f-2d74-4e07-8439-0190600c36cc@github.com>

On Thu, 27 Jun 2024 06:44:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> On macOS, when binding a datagram socket to the wildcard address with port 0, or when connecting an unbound socket (which ends up binding the socket to the wildacrd with port 0 first), the system may assign a port which is already used by another socket for a different local address. When that happens, a datagram may get misrouted which explains the intermittent failures where the test is blocked in receive().

This pull request has now been integrated.

Changeset: 8ec378a6
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ec378a6c8a460dd0727df800419b3cf45d3c57a
Stats:     61 lines in 2 files changed: 51 ins; 0 del; 10 mod

8277949: (dc) java/nio/channels/DatagramChannel/AdaptorBasic.java failed in timeout

Reviewed-by: jpai

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

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

From dfuchs at openjdk.org  Fri Jun 28 11:16:26 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Jun 2024 11:16:26 GMT
Subject: Integrated: 8299813: java/nio/channels/DatagramChannel/Disconnect.java
 fails with jtreg test timeout due to lost datagram
In-Reply-To: <JmCyUr3Ah7W5Q5H5TW0s3fs_OG_MM66Macg8qhkZb-o=.30cb9e2e-f653-4664-8501-1031a80c6440@github.com>
References: <JmCyUr3Ah7W5Q5H5TW0s3fs_OG_MM66Macg8qhkZb-o=.30cb9e2e-f653-4664-8501-1031a80c6440@github.com>
Message-ID: <zB24r2074nFyejfHu-0XXwf2XVgdLi1XmKfBpRCk_ZA=.2a92aedc-a43b-4a09-8ea1-cdca93d54d56@github.com>

On Wed, 26 Jun 2024 14:15:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a simple fix to solve an intermittent failure in  java/nio/channels/DatagramChannel/Disconnect.java
> 
> On some platform, the underlying system may allow two datagram sockets to bind to the same port, if one of them uses the wildcard address and the other doesn't.
> 
> What happens here is that during DC:connect, if the socket is unbound, it will get bound to the wildcard.
> From time to time, this results into binding to the same port that the `server` is using in the test.
> When that happens, datagram sent to the connected server may get misrouted and may not get delivered, and the call server::receive may block forever.
> 
> This change does two things: 
>   1. explicitly  bind the server to the loopback address instead of InetAddress.getLocalHost()
>   2. skip the receive part of the test if the client local address obtained after connecting uses the same port than the server. 
>   
> This is rare, and skipping the receive part in that case does not invalidate the test.

This pull request has now been integrated.

Changeset: 49eb00da
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/49eb00da8dc66cff3ca430f06ab21357ee6180ef
Stats:     32 lines in 1 file changed: 19 ins; 0 del; 13 mod

8299813: java/nio/channels/DatagramChannel/Disconnect.java fails with jtreg test timeout due to lost datagram

Reviewed-by: aefimov

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

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

From dfuchs at openjdk.org  Fri Jun 28 14:09:30 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Jun 2024 14:09:30 GMT
Subject: [jdk23] RFR: 8333849: (dc) DatagramChannel send/receive fails with UOE
 if buffer backed by memory segment allocated from shared arena
Message-ID: <weEme9slwIUDeHKp5CoO6B9atjDrBX4OCLiB1xhT9go=.3104125f-ef57-4e8f-a9eb-f34174650a74@github.com>

Hi, this is a clean backport of [JDK-8333849](https://bugs.openjdk.org/browse/JDK-8333849) to JDK 23.

JDK-8333849 fixes a bug that prevents using ByteBuffers derived from MemorySegments allocated from a shared arena with DatagramChannel. I believe the fix is important enough to justify backporting it to JDK 23 in this phase.

The fix, and test, have soaked in the mainline for two weeks already - without causing any regression.

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

Commit messages:
 - Backport e7dc76b5776e05082281fb640d1592479cfe9e6b

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

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

From alanb at openjdk.org  Fri Jun 28 14:09:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Jun 2024 14:09:30 GMT
Subject: [jdk23] RFR: 8333849: (dc) DatagramChannel send/receive fails with
 UOE if buffer backed by memory segment allocated from shared arena
In-Reply-To: <weEme9slwIUDeHKp5CoO6B9atjDrBX4OCLiB1xhT9go=.3104125f-ef57-4e8f-a9eb-f34174650a74@github.com>
References: <weEme9slwIUDeHKp5CoO6B9atjDrBX4OCLiB1xhT9go=.3104125f-ef57-4e8f-a9eb-f34174650a74@github.com>
Message-ID: <ncqy7dobhRuWNopFxEhr0UpOG_sEnVMum1xUwo1Iv9g=.dcaa2ccb-01fd-42c8-8ca4-059353d3968f@github.com>

On Fri, 28 Jun 2024 14:03:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, this is a clean backport of [JDK-8333849](https://bugs.openjdk.org/browse/JDK-8333849) to JDK 23.
> 
> JDK-8333849 fixes a bug that prevents using ByteBuffers derived from MemorySegments allocated from a shared arena with DatagramChannel. I believe the fix is important enough to justify backporting it to JDK 23 in this phase.
> 
> The fix, and test, have soaked in the mainline for two weeks already - without causing any regression.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19941#pullrequestreview-2148131642

From dfuchs at openjdk.org  Fri Jun 28 15:32:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Jun 2024 15:32:17 GMT
Subject: [jdk23] RFR: 8333849: (dc) DatagramChannel send/receive fails with
 UOE if buffer backed by memory segment allocated from shared arena
In-Reply-To: <weEme9slwIUDeHKp5CoO6B9atjDrBX4OCLiB1xhT9go=.3104125f-ef57-4e8f-a9eb-f34174650a74@github.com>
References: <weEme9slwIUDeHKp5CoO6B9atjDrBX4OCLiB1xhT9go=.3104125f-ef57-4e8f-a9eb-f34174650a74@github.com>
Message-ID: <5yzNFK3OGPWC-bxBy_JsdigFkj6Nt6vmb85gXIU4YQE=.e51977a8-0ee5-43f0-8d52-80aaacf3b373@github.com>

On Fri, 28 Jun 2024 14:03:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, this is a clean backport of [JDK-8333849](https://bugs.openjdk.org/browse/JDK-8333849) to JDK 23.
> 
> JDK-8333849 fixes a bug that prevents using ByteBuffers derived from MemorySegments allocated from a shared arena with DatagramChannel. I believe the fix is important enough to justify backporting it to JDK 23 in this phase.
> 
> The fix, and test, have soaked in the mainline for two weeks already - without causing any regression.

Running tier1, tier2, tier3 - will integrate when results come back

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

PR Comment: https://git.openjdk.org/jdk/pull/19941#issuecomment-2197182262

From eirbjo at openjdk.org  Sat Jun 29 18:24:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 29 Jun 2024 18:24:46 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v5]
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>

> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
> 
> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
> 
> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
> 
> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
> 
> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
> 
> As a note to reviewers, this PR includes the following intended updates:
> 
> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
> - Updated copyright in all affected files
> 
> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
> 
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
> 
> 
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"

Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into zipentry-external-attributes
 - Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes
 - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes
 - For clarity, use "externalFileAttributes" instead of "externalAttributes"
 - Merge branch 'master' into zipentry-external-attributes
 - Update copyright years for 2024
 - Merge branch 'master' into zipentry-external-attributes
 - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

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

Changes: https://git.openjdk.org/jdk/pull/16952/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=04
  Stats: 56 lines in 12 files changed: 0 ins; 4 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/16952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16952/head:pull/16952

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

From eirbjo at openjdk.org  Sat Jun 29 18:24:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 29 Jun 2024 18:24:46 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v4]
In-Reply-To: <9mdtCM7usK43fFPhH1w4Et3xYPtlqwwBYq6OWPfVa9A=.fb4d8f4e-250d-4dc6-a1ce-446f09bb00f5@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
 <9mdtCM7usK43fFPhH1w4Et3xYPtlqwwBYq6OWPfVa9A=.fb4d8f4e-250d-4dc6-a1ce-446f09bb00f5@github.com>
Message-ID: <gKjp0nyzMBkSSTPjb8AFIw1FbpHVyJmwn-25t4eOGxA=.c95e9ca2-45c8-4b36-95cb-403827f7f5b9@github.com>

On Sun, 12 May 2024 14:37:23 GMT, Chen Liang <liach at openjdk.org> wrote:

> I believe this field only captures the 2 bytes at higher indices of External File Attribute; it's not the complete 4-byte external file attributes and this value is not captured unless "Version made by" field's larger index byte (byte 5) is 3. So this name may still be imperfect.

The purpose of this PR was mainly to reduce the risk of confusion with the "extra field", which is an entirely unrelated concept.

While I agree that the name `externalFileAttributes` might not express the full semantics of the field perfectly, I'm honestly not sure which name would, given that `APPNOTE.TXT` is pretty opaque in describing what these two bytes express, and as you point out, the field only carries data when "Version Made By" indicates Unix.

Instead of trying to find name which covers the full semantics, I suggest that we keep `externalFileAttributes` and instead seek to improve the comments relevant to this field:

* The field comment currently says `// File type, setuid, setgid, sticky, POSIX permissions`, we could prepend something clarifying that the field only carries data for Unix entries.
* Line 699 says `// read all bits in this field, including sym link attributes`, this could be improved to clarify that only the higher two "unix-bytes" are read ("all bits in this field" is a bit unclear now)
* Line 700 masks off the Unix bytes with `0xFFFF`, this isn't strictly necessary since `CENATX_PERMS` already only reads the two bytes we want. Perhaps clearer just to drop this masking.
* `ZipUtils.CENATX_PERMS` reads the full 16 bits of the Unix external file attributes, not just the permissions. The current name is confusing.

Since I don't want to delay the integration of the this PR any further, I suggest we tackle the above clarifications in a follow-up PR. Would that be ok with you, @liach ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2198283812

From eirbjo at openjdk.org  Sat Jun 29 18:24:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 29 Jun 2024 18:24:46 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v4]
In-Reply-To: <iF6bpMXAAU3joVhZJwGU3bTPx6dBEZnYAtHgY-sJCPE=.6ffacb24-ab34-48d2-8120-68dd93a60dba@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
 <iF6bpMXAAU3joVhZJwGU3bTPx6dBEZnYAtHgY-sJCPE=.6ffacb24-ab34-48d2-8120-68dd93a60dba@github.com>
Message-ID: <J7HUrQoDGQzfTPObFhpkvw4GcDJ9PGXwvRQ6gj79Bx4=.69c20e3b-1d15-403d-8ed6-303116691a24@github.com>

On Thu, 9 May 2024 12:00:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Eirik, it will be better to merge with the latest master branch and run the tier tests before integrating.

Life happened, but I have now merged with the latest master and GHA runs green.

Did you want to run additional testing before integration @jaikiran ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2198284302

From jpai at openjdk.org  Sun Jun 30 04:51:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 30 Jun 2024 04:51:31 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v5]
In-Reply-To: <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>
Message-ID: <A1CrpCUTWpIWJYwh0OPZHZAvHkkyuOm9WIga5jl2tRs=.c23b1d13-e7f5-4b41-a392-feceae50606e@github.com>

On Sat, 29 Jun 2024 18:24:46 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
>> 
>> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
>> 
>> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
>> 
>> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
>> 
>> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
>> 
>> As a note to reviewers, this PR includes the following intended updates:
>> 
>> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
>> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
>> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
>> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
>> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
>> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
>> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
>> - Updated copyright in all affected files
>> 
>> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
>> 
>> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
>> 
>> 
>> make test TEST="test/jdk/java/util/jar"
>> make test TEST="test/jdk/java/util/zip"
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes
>  - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes
>  - For clarity, use "externalFileAttributes" instead of "externalAttributes"
>  - Merge branch 'master' into zipentry-external-attributes
>  - Update copyright years for 2024
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

Hello Eirik, I'll run some tests and review this PR this coming week.

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2198432408