From alanb at openjdk.java.net  Sat Jan  2 17:32:58 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 2 Jan 2021 17:32:58 GMT
Subject: [jdk16] RFR: 8258955: (bf) slice(int,
 int) on view buffers fails to adjust index according to primitive size
In-Reply-To: <l98HM1lQ-c3opT4TbOzCGEBVa_q4HYUKpDXYoXl7JNg=.64dd0550-0d28-41df-940d-22faa1bee4c2@github.com>
References: <l98HM1lQ-c3opT4TbOzCGEBVa_q4HYUKpDXYoXl7JNg=.64dd0550-0d28-41df-940d-22faa1bee4c2@github.com>
Message-ID: <W7L673dfHvyAz3d2a2uEnsB9dEbx3lvi1YVuc0mBkdk=.76028845-1024-4dcf-b094-16862de0411c@github.com>

On Wed, 30 Dec 2020 16:12:43 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Scale the slice start index per carrier width, for views of direct byte buffers. This never worked correctly since being added in Java 13.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/73

From chegar at openjdk.java.net  Sat Jan  2 19:32:58 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Sat, 2 Jan 2021 19:32:58 GMT
Subject: [jdk16] Integrated: 8258955: (bf) slice(int,
 int) on view buffers fails to adjust index according to primitive size
In-Reply-To: <l98HM1lQ-c3opT4TbOzCGEBVa_q4HYUKpDXYoXl7JNg=.64dd0550-0d28-41df-940d-22faa1bee4c2@github.com>
References: <l98HM1lQ-c3opT4TbOzCGEBVa_q4HYUKpDXYoXl7JNg=.64dd0550-0d28-41df-940d-22faa1bee4c2@github.com>
Message-ID: <GBZEGHzKfNDt3RSzTJ4s1tTocbd9Muzh-_m_MuanMUk=.bff94f3f-1af7-4e85-8dc5-51beda7af5b3@github.com>

On Wed, 30 Dec 2020 16:12:43 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Scale the slice start index per carrier width, for views of direct byte buffers. This never worked correctly since being added in Java 13.

This pull request has now been integrated.

Changeset: 73f54153
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/73f54153
Stats:     35 lines in 2 files changed: 31 ins; 0 del; 4 mod

8258955: (bf) slice(int, int) on view buffers fails to adjust index according to primitive size

Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk16/pull/73

From github.com+471021+marschall at openjdk.java.net  Mon Jan  4 17:50:10 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Mon, 4 Jan 2021 17:50:10 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v2]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <JXlsEiP6ji1qvL3p8rqZL1GvCPY2QVU4cz_ln6l6T6M=.c1aee1a8-db72-42f5-ba8f-ce3c775eebd4@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

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

  Fix off-heap code path
  
  The off-heap code path was missing a buffer.put

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/967b314a..a88cd931

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From bpb at openjdk.java.net  Tue Jan  5 00:53:00 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 5 Jan 2021 00:53:00 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
Message-ID: <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>

On Thu, 31 Dec 2020 10:11:58 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> A couple of implementation notes:
> 
> Reader#read(CharBuffer)
> 
> on-heap case
> 
> I introduced a dedicated path for the on-heap case and directly read into the backing array. This completely avoids the intermediate allocation and copy. Compared to the initial proposal the buffer position is updated. This has to be done because we bypass the buffer and directly read into the array. This also handles the case that #read returns -1.
> 
> I am using a c-style array declaration because the rest of the class uses it.
> 
> off-heap case
> 
> I limit the intermadiate allocation to TRANSFER_BUFFER_SIZE. In order to reduce the total intermediate allocation we now call #read multiple times until the buffer is full or EOF is reached. This changes the behavior slightly as now possibly more data is read. However this should contribute to reduce the overall intermediate allocations.
> 
> A lock is acquired to keep the the read atomic. This is consistent with #skip which also holds a lock over multiple #read calls. This is inconsistent with #transferTo which does not acquire a lock over multiple #read calls. 
> 
> The implementation took inspiration from java.io.InputStream#readNBytes(int).
> 
> InputStreamReader#read(CharBuffer)
> 
> Since StreamDecoder is a Reader as well we can simply delegate.
> 
> StreamDecoder#read(CharBuffer)
> 
> Interestingly this was not implemented even though StreamDecoder internally works on NIO buffers.
> 
> on-heap case
> 
> We see a performance improvement and the elimination of all intermediate allocation.
> 
> StreamDecoder#read(char[], int, int) and InputStreamReader#read(char[], int, int) may get a small improvement as we no longer #slice the buffer.
> 
> off-heap case
> 
> We see the elimination of all intermediate allocation but a performance penalty because we hit the slow path in #decodeLoop. There is a trade-off here, we could improve the performance to previous levels by introducing intermediate allocation again. I don't know how much the users of off-heap buffers care about introducing intermediate allocation vs maximum throughput.
> 
> I was struggling to come up with microbenchmarks because the built in InputStream and Reader implementations are finite but JMH calls the benchmark methods repeatably. I ended up implementing custom infinite InputStream and Reader implementations. The code can be found there:
> 
> https://github.com/marschall/reader-benchmarks/tree/master/src/main/java/com/github/marschall/readerbenchmarks
> 
> An Excel with charts can be found here:
> 
> https://github.com/marschall/reader-benchmarks/raw/master/src/main/resources/4926314.xlsx
> 
> I looked for java.io.Reader#read(CharBuffer) users in the JDK and only found java.util.Scanner#readInput(). I wrote a microbenchmark for this but only found minuscule improvements due to regex dominating the runtime.
> 
> There seem to be no direct Reader tests in the tier1 suite, the initial code was wrong because I forgot to update the buffer code position but I only found out because some Scanner tests failed.

I changed the JBS issue summary to match the title of this PR so that integration blocker is removed.

How does the performance of `InputStreamReader.read(CharBuffer)` compare for the case where only the change to `Reader` is made versus if all your proposed changes are applied?

Some kind of specific test should likely be included.

Note that the more recent copyright year is now 2021.

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From mcimadamore at openjdk.java.net  Tue Jan  5 15:39:01 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 5 Jan 2021 15:39:01 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
Message-ID: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>

Hi,
this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).

To test this I had to break open into FileChannelImpl and ready the granularity.

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

Commit messages:
 - Fix issue in Unmapper implementation not including `pagePosition` in address computation

Changes: https://git.openjdk.java.net/jdk16/pull/84/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=84&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259032
  Stats: 32 lines in 2 files changed: 30 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/84.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/84/head:pull/84

PR: https://git.openjdk.java.net/jdk16/pull/84

From alanb at openjdk.java.net  Tue Jan  5 15:47:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 5 Jan 2021 15:47:57 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
Message-ID: <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>

On Tue, 5 Jan 2021 15:33:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Hi,
> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
> 
> To test this I had to break open into FileChannelImpl and ready the granularity.

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

> 26:  * @modules java.base/sun.nio.ch
> 27:  *          jdk.incubator.foreign/jdk.internal.foreign
> 28:  * @run testng/othervm --illegal-access=permit -Dforeign.restricted=permit TestByteBuffer

Can you change java.base/sun.nio.ch to java.base/sun.nio.ch:+open instead? That would avoid the --illegal-access=permit.

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From uschindler at openjdk.java.net  Tue Jan  5 15:57:57 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 5 Jan 2021 15:57:57 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
 <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>
Message-ID: <rfSd13qs3N61u-RQdxTj1YW6-e7I8yf4zSvrHu6pYjQ=.88db13d2-4fb8-498f-9daa-428ce41e4fe9@github.com>

On Tue, 5 Jan 2021 15:44:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
>> 
>> To test this I had to break open into FileChannelImpl and ready the granularity.
>
> test/jdk/java/foreign/TestByteBuffer.java line 28:
> 
>> 26:  * @modules java.base/sun.nio.ch
>> 27:  *          jdk.incubator.foreign/jdk.internal.foreign
>> 28:  * @run testng/othervm --illegal-access=permit -Dforeign.restricted=permit TestByteBuffer
> 
> Can you change java.base/sun.nio.ch to java.base/sun.nio.ch:+open instead? That would avoid the --illegal-access=permit.

I am not sure if a test like this is really needed.
The alignment is pageSize on Linux and some arbitrary value (65536) on Windows. If you have some test file that writes like a few bytes (1, 2, 3, 4,...) To a file and then maps it with offsets other than zero, you just have to get the first byte and compare it to offset.

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From uschindler at openjdk.java.net  Tue Jan  5 16:06:56 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 5 Jan 2021 16:06:56 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <rfSd13qs3N61u-RQdxTj1YW6-e7I8yf4zSvrHu6pYjQ=.88db13d2-4fb8-498f-9daa-428ce41e4fe9@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
 <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>
 <rfSd13qs3N61u-RQdxTj1YW6-e7I8yf4zSvrHu6pYjQ=.88db13d2-4fb8-498f-9daa-428ce41e4fe9@github.com>
Message-ID: <BBIK5-AVrPp_Zwflq2j9rDyCJC6DCTgh0ANm9JHDPJY=.b8eb8956-9ad0-4ce9-bbef-99c6796d62b1@github.com>

On Tue, 5 Jan 2021 15:55:10 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> test/jdk/java/foreign/TestByteBuffer.java line 28:
>> 
>>> 26:  * @modules java.base/sun.nio.ch
>>> 27:  *          jdk.incubator.foreign/jdk.internal.foreign
>>> 28:  * @run testng/othervm --illegal-access=permit -Dforeign.restricted=permit TestByteBuffer
>> 
>> Can you change java.base/sun.nio.ch to java.base/sun.nio.ch:+open instead? That would avoid the --illegal-access=permit.
>
> I am not sure if a test like this is really needed.
> The alignment is pageSize on Linux and some arbitrary value (65536) on Windows. If you have some test file that writes like a few bytes (1, 2, 3, 4,...) To a file and then maps it with offsets other than zero, you just have to get the first byte and compare it to offset.

In fact the new test only checks if everything is aligned like we expect, but it does not test that our mapping returns a memory segment with expected contents.

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From uschindler at openjdk.java.net  Tue Jan  5 16:06:56 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 5 Jan 2021 16:06:56 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <BBIK5-AVrPp_Zwflq2j9rDyCJC6DCTgh0ANm9JHDPJY=.b8eb8956-9ad0-4ce9-bbef-99c6796d62b1@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
 <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>
 <rfSd13qs3N61u-RQdxTj1YW6-e7I8yf4zSvrHu6pYjQ=.88db13d2-4fb8-498f-9daa-428ce41e4fe9@github.com>
 <BBIK5-AVrPp_Zwflq2j9rDyCJC6DCTgh0ANm9JHDPJY=.b8eb8956-9ad0-4ce9-bbef-99c6796d62b1@github.com>
Message-ID: <dA3VqCIVGItosjmklXMYrwD7CiIe8emJdiJqt_Ov-BQ=.0c14b436-2ad4-4c96-ad6f-de1af6d21666@github.com>

On Tue, 5 Jan 2021 16:01:11 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> I am not sure if a test like this is really needed.
>> The alignment is pageSize on Linux and some arbitrary value (65536) on Windows. If you have some test file that writes like a few bytes (1, 2, 3, 4,...) To a file and then maps it with offsets other than zero, you just have to get the first byte and compare it to offset.
>
> In fact the new test only checks if everything is aligned like we expect, but it does not test that our mapping returns a memory segment with expected contents.

So I tend to make a simple test without reflection that writes a defined sequence of bytes to a file and then maps it with various offsets, checking that the first byte in the mapped segment is from that sequence.

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From mcimadamore at openjdk.java.net  Tue Jan  5 16:15:57 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 5 Jan 2021 16:15:57 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <dA3VqCIVGItosjmklXMYrwD7CiIe8emJdiJqt_Ov-BQ=.0c14b436-2ad4-4c96-ad6f-de1af6d21666@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
 <6k21VP3g6k6xubRsu9fCvTKcLMJksumesEI4SXXSVP0=.6897afa5-5af0-484a-8c82-3ef39d6da606@github.com>
 <rfSd13qs3N61u-RQdxTj1YW6-e7I8yf4zSvrHu6pYjQ=.88db13d2-4fb8-498f-9daa-428ce41e4fe9@github.com>
 <BBIK5-AVrPp_Zwflq2j9rDyCJC6DCTgh0ANm9JHDPJY=.b8eb8956-9ad0-4ce9-bbef-99c6796d62b1@github.com>
 <dA3VqCIVGItosjmklXMYrwD7CiIe8emJdiJqt_Ov-BQ=.0c14b436-2ad4-4c96-ad6f-de1af6d21666@github.com>
Message-ID: <98zeUvOyyXJSIqA7bs-K2krugdkrkWK12aFunEVWUcc=.d8a7158c-a6b0-4d01-9426-6bc869eee66e@github.com>

On Tue, 5 Jan 2021 16:03:04 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> In fact the new test only checks if everything is aligned like we expect, but it does not test that our mapping returns a memory segment with expected contents.
>
> So I tend to make a simple test without reflection that writes a defined sequence of bytes to a file and then maps it with various offsets, checking that the first byte in the mapped segment is from that sequence.

Good suggestion!

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From mcimadamore at openjdk.java.net  Tue Jan  5 17:28:10 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 5 Jan 2021 17:28:10 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition [v2]
In-Reply-To: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
Message-ID: <ioK4uSSuUrjGcdnoJ89hWcfoFOUbwSrhVMG9aozZIzE=.b3308414-1528-4152-acba-87fa764ade8b@github.com>

> Hi,
> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
> 
> To test this I had to break open into FileChannelImpl and ready the granularity.

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

  Simplify test not to depend on implementation internals

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/84/files
  - new: https://git.openjdk.java.net/jdk16/pull/84/files/b58a381c..7a78d724

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=84&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=84&range=00-01

  Stats: 25 lines in 1 file changed: 7 ins; 14 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/84.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/84/head:pull/84

PR: https://git.openjdk.java.net/jdk16/pull/84

From github.com+471021+marschall at openjdk.java.net  Tue Jan  5 17:44:20 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 5 Jan 2021 17:44:20 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

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

  Update copyright years

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/a88cd931..8d405587

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915

PR: https://git.openjdk.java.net/jdk/pull/1915

From kustos at gmx.net  Tue Jan  5 17:53:06 2021
From: kustos at gmx.net (Philippe Marschall)
Date: Tue, 5 Jan 2021 18:53:06 +0100
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
 <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
Message-ID: <415bcf9c-e257-9fe5-1ff0-97a6c45b9a41@gmx.net>



On 05.01.21 01:53, Brian Burkhalter wrote:
> ...
>
> I changed the JBS issue summary to match the title of this PR so that integration blocker is removed.

Thank you.

> How does the performance of `InputStreamReader.read(CharBuffer)` compare for the case where only the change to `Reader` is made versus if all your proposed changes are applied?

I can look into this, this will take a moment. I guess it would also
make sense to have a comparison with a version that does intermediate
heap allocation for off-heap buffers in InputStreamReader#read(CharBuffer).

> Some kind of specific test should likely be included.

Sure. The existing tests in this area seem to be #main-based. Would you
prefer #main based tests or TestNG tests?

> Note that the more recent copyright year is now 2021.

Indeed it is, fixed.

Cheers
Philippe

From brian.burkhalter at oracle.com  Tue Jan  5 18:08:19 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 5 Jan 2021 10:08:19 -0800
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <415bcf9c-e257-9fe5-1ff0-97a6c45b9a41@gmx.net>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
 <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
 <415bcf9c-e257-9fe5-1ff0-97a6c45b9a41@gmx.net>
Message-ID: <DCA62E36-DD65-4CA7-8C7D-E0C90B5C4A6E@oracle.com>


> On Jan 5, 2021, at 9:53 AM, Philippe Marschall <kustos at gmx.net> wrote:
> 
>> How does the performance of `InputStreamReader.read(CharBuffer)` compare for the case where only the change to `Reader` is made versus if all your proposed changes are applied?
> 
> I can look into this, this will take a moment. I guess it would also
> make sense to have a comparison with a version that does intermediate
> heap allocation for off-heap buffers in InputStreamReader#read(CharBuffer).

If you like. I was just wondering whether the change to Reader.read(CharBuffer) would be enough.

>> Some kind of specific test should likely be included.
> 
> Sure. The existing tests in this area seem to be #main-based. Would you
> prefer #main based tests or TestNG tests?

For new tests we seem to be preferring Tests NG.

>> Note that the more recent copyright year is now 2021.
> 
> Indeed it is, fixed.

Thanks.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210105/0de0aedc/attachment-0001.htm>

From alanb at openjdk.java.net  Tue Jan  5 20:01:00 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 5 Jan 2021 20:01:00 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition [v2]
In-Reply-To: <ioK4uSSuUrjGcdnoJ89hWcfoFOUbwSrhVMG9aozZIzE=.b3308414-1528-4152-acba-87fa764ade8b@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
 <ioK4uSSuUrjGcdnoJ89hWcfoFOUbwSrhVMG9aozZIzE=.b3308414-1528-4152-acba-87fa764ade8b@github.com>
Message-ID: <3zS2UwSEWBPJt-YvPvSLYDP1arY5BzYL2IxMoo0EvZo=.96bae7e6-37a1-48a7-b9ec-79ab7d264801@github.com>

On Tue, 5 Jan 2021 17:28:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi,
>> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
>> 
>> To test this I had to break open into FileChannelImpl and ready the granularity.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify test not to depend on implementation internals

Good suggestion from Uwe.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/84

From uschindler at openjdk.java.net  Tue Jan  5 19:41:59 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 5 Jan 2021 19:41:59 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition
In-Reply-To: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
Message-ID: <oC_c14bF3vLyUclYQNw66jC9u6Mx3Lmq36IfpX9gTk0=.13c63b2e-ce87-4768-8c8e-b7cad260e813@github.com>

On Tue, 5 Jan 2021 15:33:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Hi,
> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
> 
> To test this I had to break open into FileChannelImpl and ready the granularity.

Hi,
The new test looks fine to me.
Uwe

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From mcimadamore at openjdk.java.net  Wed Jan  6 12:22:11 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 6 Jan 2021 12:22:11 GMT
Subject: [jdk16] RFR: 8259032: MappedMemorySegmentImpl#makeMappedSegment()
 ignores Unmapper#pagePosition [v3]
In-Reply-To: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
Message-ID: <P7TguVL_o-BnwQh92jFcyJ4TZoZkSvnAdXj1AaTeydY=.3177ff16-447f-4245-9c44-20f9f0a7f2b9@github.com>

> Hi,
> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
> 
> To test this I had to break open into FileChannelImpl and ready the granularity.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into 8259032_pagepos
 - Simplify test not to depend on implementation internals
 - Fix issue in Unmapper implementation not including `pagePosition` in address computation

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

Changes: https://git.openjdk.java.net/jdk16/pull/84/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=84&range=02
  Stats: 23 lines in 2 files changed: 22 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/84.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/84/head:pull/84

PR: https://git.openjdk.java.net/jdk16/pull/84

From mcimadamore at openjdk.java.net  Wed Jan  6 12:22:12 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 6 Jan 2021 12:22:12 GMT
Subject: [jdk16] Integrated: 8259032:
 MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition
In-Reply-To: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
References: <0ajpJtLi4OBLJEZiLEtzGu107eV1HM5XYuMJgSt1e9A=.faacddbb-b563-49cd-bcc8-7e31a464f72e@github.com>
Message-ID: <5TOdOdUJT-N3v_rxpxtyGGt7ZKe1I2u_25kdJThuLXQ=.c4560205-c9dc-4673-a11a-bfb338fa25d5@github.com>

On Tue, 5 Jan 2021 15:33:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Hi,
> this patch fixes an oversight where the address() method in FileChannelImpl.Unmapper does not take into account the value of `pagePosition` - this leads to a situation in which, effectively, the specified offset when mapping the segment is ignored by the runtime (because base address will always be aligned to some known quantity - which is OS/platform dependent).
> 
> To test this I had to break open into FileChannelImpl and ready the granularity.

This pull request has now been integrated.

Changeset: e66187d8
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/e66187d8
Stats:     23 lines in 2 files changed: 22 ins; 0 del; 1 mod

8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition

Co-authored-by: Uwe Schindler <uschindler at openjdk.org>
Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk16/pull/84

From bpb at openjdk.java.net  Thu Jan  7 00:07:08 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 7 Jan 2021 00:07:08 GMT
Subject: RFR: 8259274: Increase timeout duration in
 sun/nio/ch/TestMaxCachedBufferSize.java
Message-ID: <qonwXyF9p5wBMeU1J8RxpFv8MzDl_awVHVYW7mwGiO0=.8e061cb7-d0b3-4ec0-a17b-23c9fac443cf@github.com>

The change for JDK-8255913 integrated on 2020-11-05 reduced by half the number of iterations in `TestMaxCachedBufferSize`. As reported in JDK-8212812 on 2021-01-05, the test still failed due to a timeout after an elapsed time of 502738ms including timeout handling. The current timeout is 480000ms which represents the default timeout of 120s multiplied by the timeout factor of 4.

The present change proposes to increase the timeout by 25% to 150s. This should hopefully dispense with the ongoing test timeouts. As these timeouts have been observed primarily if not exclusively on decade-old MacPro5_1 machines, the timeout should not appreciably increase the overall CI test execution time.

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

Commit messages:
 - 8259274: Increase timeout duration in sun/nio/ch/TestMaxCachedBufferSize.java

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

PR: https://git.openjdk.java.net/jdk/pull/1969

From lancea at openjdk.java.net  Thu Jan  7 00:59:55 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 7 Jan 2021 00:59:55 GMT
Subject: RFR: 8259274: Increase timeout duration in
 sun/nio/ch/TestMaxCachedBufferSize.java
In-Reply-To: <qonwXyF9p5wBMeU1J8RxpFv8MzDl_awVHVYW7mwGiO0=.8e061cb7-d0b3-4ec0-a17b-23c9fac443cf@github.com>
References: <qonwXyF9p5wBMeU1J8RxpFv8MzDl_awVHVYW7mwGiO0=.8e061cb7-d0b3-4ec0-a17b-23c9fac443cf@github.com>
Message-ID: <9y_ab2RvzV7Q9_8Gyc6a-eOz7ZqaqpdvyRPCMjH0ulE=.1b10acba-19ef-45ae-b08f-5b1cc2de53f2@github.com>

On Thu, 7 Jan 2021 00:00:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The change for JDK-8255913 integrated on 2020-11-05 reduced by half the number of iterations in `TestMaxCachedBufferSize`. As reported in JDK-8212812 on 2021-01-05, the test still failed due to a timeout after an elapsed time of 502738ms including timeout handling. The current timeout is 480000ms which represents the default timeout of 120s multiplied by the timeout factor of 4.
> 
> The present change proposes to increase the timeout by 25% to 150s. This should hopefully dispense with the ongoing test timeouts. As these timeouts have been observed primarily if not exclusively on decade-old MacPro5_1 machines, the timeout should not appreciably increase the overall CI test execution time.

Seems like a reasonable means to address the issue

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1969

From michaelm at openjdk.java.net  Thu Jan  7 19:33:08 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 7 Jan 2021 19:33:08 GMT
Subject: RFR: 8259014: (so)
 ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress)
 will have unknown user and group owner (win)
Message-ID: <bjxD3UO8tNvYUrLNG46Cb0057VRThwgabSJseZd54bk=.d6023750-c8df-498b-a78a-6982e3a8b349@github.com>

Hi,

Could I get the following fix reviewed please? There is a bug in Windows (2019) relating to the handling of Unix domain socket files such that special file options have to be used when opening the files. This causes problems for Cygwin and the Java file APIs. The bug has been fixed in more recent Windows builds. So, Windows 10 is not affected, but the fix here is to disable support for Unix domain sockets in the affected Windows builds. More recent Windows Server versions are probably not affected either.

Thanks
Michael

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

Commit messages:
 - Test for Windows OS build >= 18362

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

PR: https://git.openjdk.java.net/jdk/pull/1986

From alanb at openjdk.java.net  Thu Jan  7 20:07:56 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 7 Jan 2021 20:07:56 GMT
Subject: RFR: 8259014: (so)
 ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress)
 will have unknown user and group owner (win)
In-Reply-To: <bjxD3UO8tNvYUrLNG46Cb0057VRThwgabSJseZd54bk=.d6023750-c8df-498b-a78a-6982e3a8b349@github.com>
References: <bjxD3UO8tNvYUrLNG46Cb0057VRThwgabSJseZd54bk=.d6023750-c8df-498b-a78a-6982e3a8b349@github.com>
Message-ID: <kn5K8RBmwxk5HkUx4bYJujAboJHaIBEWksAdjGK8LvY=.507de058-920c-45f8-91f1-b7d65688e59a@github.com>

On Thu, 7 Jan 2021 19:27:45 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following fix reviewed please? There is a bug in Windows (2019) relating to the handling of Unix domain socket files such that special file options have to be used when opening the files. This causes problems for Cygwin and the Java file APIs. The bug has been fixed in more recent Windows builds. So, Windows 10 is not affected, but the fix here is to disable support for Unix domain sockets in the affected Windows builds. More recent Windows Server versions are probably not affected either.
> 
> Thanks
> Michael

src/java.base/windows/native/libnio/ch/UnixDomainSockets.c line 110:

> 108:     if (osver.dwBuildNumber < 18362) {
> 109:         return JNI_FALSE;
> 110:     }

Can you use VerifyVersionInfoW instead of the deprecated GetVersionEx? The IsWindows10RS3OrGreater function in net_util_md.c is a recent example.

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

PR: https://git.openjdk.java.net/jdk/pull/1986

From jwilhelm at openjdk.java.net  Thu Jan  7 20:45:15 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 7 Jan 2021 20:45:15 GMT
Subject: RFR: Merge jdk16
Message-ID: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8249633: doclint reports missing javadoc for JavaFX property methods that have a property description
 - 8251200: False positive messages about missing comments for serialization
 - 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days
 - 8259075: Update the copyright notice in the files generated by CLDR Converter tool
 - 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes
 - 8258558: Revert changes for JDK-8252505 and related issues
 - 8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition
 - 8259007: This test printed a blank page
 - 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/0e6de4eb...bbd6426f

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/1989/files
  Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1989.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1989/head:pull/1989

PR: https://git.openjdk.java.net/jdk/pull/1989

From bpb at openjdk.java.net  Thu Jan  7 21:00:57 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 7 Jan 2021 21:00:57 GMT
Subject: Integrated: 8259274: Increase timeout duration in
 sun/nio/ch/TestMaxCachedBufferSize.java
In-Reply-To: <qonwXyF9p5wBMeU1J8RxpFv8MzDl_awVHVYW7mwGiO0=.8e061cb7-d0b3-4ec0-a17b-23c9fac443cf@github.com>
References: <qonwXyF9p5wBMeU1J8RxpFv8MzDl_awVHVYW7mwGiO0=.8e061cb7-d0b3-4ec0-a17b-23c9fac443cf@github.com>
Message-ID: <LJN1Ehu9Lde3JINl4KdyTC1CeeaMzVeyrnaZM_LzVN0=.fa07dcbb-178b-443e-b44a-c404fb807ed0@github.com>

On Thu, 7 Jan 2021 00:00:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The change for JDK-8255913 integrated on 2020-11-05 reduced by half the number of iterations in `TestMaxCachedBufferSize`. As reported in JDK-8212812 on 2021-01-05, the test still failed due to a timeout after an elapsed time of 502738ms including timeout handling. The current timeout is 480000ms which represents the default timeout of 120s multiplied by the timeout factor of 4.
> 
> The present change proposes to increase the timeout by 25% to 150s. This should hopefully dispense with the ongoing test timeouts. As these timeouts have been observed primarily if not exclusively on decade-old MacPro5_1 machines, the timeout should not appreciably increase the overall CI test execution time.

This pull request has now been integrated.

Changeset: 2659bc44
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2659bc44
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8259274: Increase timeout duration in sun/nio/ch/TestMaxCachedBufferSize.java

Reviewed-by: lancea

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

PR: https://git.openjdk.java.net/jdk/pull/1969

From michaelm at openjdk.java.net  Thu Jan  7 21:19:01 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 7 Jan 2021 21:19:01 GMT
Subject: RFR: 8259014: (so)
 ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress)
 will have unknown user and group owner (win)
In-Reply-To: <kn5K8RBmwxk5HkUx4bYJujAboJHaIBEWksAdjGK8LvY=.507de058-920c-45f8-91f1-b7d65688e59a@github.com>
References: <bjxD3UO8tNvYUrLNG46Cb0057VRThwgabSJseZd54bk=.d6023750-c8df-498b-a78a-6982e3a8b349@github.com>
 <kn5K8RBmwxk5HkUx4bYJujAboJHaIBEWksAdjGK8LvY=.507de058-920c-45f8-91f1-b7d65688e59a@github.com>
Message-ID: <i2JScKuxbDG3EhLtPiVOeEy-wiWefqYuUuqJ0w4sdAU=.29f96274-afe8-4634-846e-d6f4618343a7@github.com>

On Thu, 7 Jan 2021 20:05:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following fix reviewed please? There is a bug in Windows (2019) relating to the handling of Unix domain socket files such that special file options have to be used when opening the files. This causes problems for Cygwin and the Java file APIs. The bug has been fixed in more recent Windows builds. So, Windows 10 is not affected, but the fix here is to disable support for Unix domain sockets in the affected Windows builds. More recent Windows Server versions are probably not affected either.
>> 
>> Thanks
>> Michael
>
> src/java.base/windows/native/libnio/ch/UnixDomainSockets.c line 110:
> 
>> 108:     if (osver.dwBuildNumber < 18362) {
>> 109:         return JNI_FALSE;
>> 110:     }
> 
> Can you use VerifyVersionInfoW instead of the deprecated GetVersionEx? The IsWindows10RS3OrGreater function in net_util_md.c is a recent example.

It looks like VerifyVersionInfoW is (or will be) deprecated also and it seems like quite a complicated API that checks the same thing in this case.

https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-verifyversioninfow

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

PR: https://git.openjdk.java.net/jdk/pull/1986

From jwilhelm at openjdk.java.net  Thu Jan  7 21:21:57 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 7 Jan 2021 21:21:57 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com>
References: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com>
Message-ID: <g7HsOL7HlE5kiLX6yzRNwvx5XNa7P_bh7ZlqKQgSMhM=.de687feb-4dbe-428e-9552-fa4b54dc2e04@github.com>

On Thu, 7 Jan 2021 20:40:49 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 555641ed
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/555641ed
Stats:     2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod

Merge

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

PR: https://git.openjdk.java.net/jdk/pull/1989

From michaelm at openjdk.java.net  Fri Jan  8 10:13:53 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 8 Jan 2021 10:13:53 GMT
Subject: RFR: 8259014: (so)
 ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress)
 will have unknown user and group owner (win)
In-Reply-To: <i2JScKuxbDG3EhLtPiVOeEy-wiWefqYuUuqJ0w4sdAU=.29f96274-afe8-4634-846e-d6f4618343a7@github.com>
References: <bjxD3UO8tNvYUrLNG46Cb0057VRThwgabSJseZd54bk=.d6023750-c8df-498b-a78a-6982e3a8b349@github.com>
 <kn5K8RBmwxk5HkUx4bYJujAboJHaIBEWksAdjGK8LvY=.507de058-920c-45f8-91f1-b7d65688e59a@github.com>
 <i2JScKuxbDG3EhLtPiVOeEy-wiWefqYuUuqJ0w4sdAU=.29f96274-afe8-4634-846e-d6f4618343a7@github.com>
Message-ID: <D6H4wwzUaJ3U_Yf2p-Br-k5JcF2l6iuzaZsINe1iZ2Q=.1df17866-5ecf-42e2-972c-3ddc83d5838d@github.com>

On Thu, 7 Jan 2021 21:15:42 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/windows/native/libnio/ch/UnixDomainSockets.c line 110:
>> 
>>> 108:     if (osver.dwBuildNumber < 18362) {
>>> 109:         return JNI_FALSE;
>>> 110:     }
>> 
>> Can you use VerifyVersionInfoW instead of the deprecated GetVersionEx? The IsWindows10RS3OrGreater function in net_util_md.c is a recent example.
>
> It looks like VerifyVersionInfoW is (or will be) deprecated also and it seems like quite a complicated API that checks the same thing in this case.
> 
> https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-verifyversioninfow

I'm going to close this PR as it should have been on the jdk16 repo. I'll also look at using the other Windows API that does not require a #pragma (for now). Will open a new PR on jdk16 shortly.

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

PR: https://git.openjdk.java.net/jdk/pull/1986

From michaelm at openjdk.java.net  Fri Jan  8 10:13:54 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 8 Jan 2021 10:13:54 GMT
Subject: Withdrawn: 8259014: (so)
 ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress)
 will have unknown user and group owner (win)
In-Reply-To: <bjxD3UO8tNvYUrLNG46Cb0057VRThwgabSJseZd54bk=.d6023750-c8df-498b-a78a-6982e3a8b349@github.com>
References: <bjxD3UO8tNvYUrLNG46Cb0057VRThwgabSJseZd54bk=.d6023750-c8df-498b-a78a-6982e3a8b349@github.com>
Message-ID: <urJdyVAnKjykoZ61RZndd1VzBnog0sjkk1n-zde-R30=.fe37ec84-2a13-4a5d-a555-34247a951b71@github.com>

On Thu, 7 Jan 2021 19:27:45 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following fix reviewed please? There is a bug in Windows (2019) relating to the handling of Unix domain socket files such that special file options have to be used when opening the files. This causes problems for Cygwin and the Java file APIs. The bug has been fixed in more recent Windows builds. So, Windows 10 is not affected, but the fix here is to disable support for Unix domain sockets in the affected Windows builds. More recent Windows Server versions are probably not affected either.
> 
> Thanks
> Michael

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/1986

From michaelm at openjdk.java.net  Fri Jan  8 12:08:14 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 8 Jan 2021 12:08:14 GMT
Subject: [jdk16] RFR: 8259014: (so)
 ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress)
 will have unknown user and group owner (win)
Message-ID: <w5h1Mbc1FHH7J3cu8Oey87Iw-11YdbF7Fg_9rd4TpEM=.4e06c2e7-0306-4566-a15d-fef270185a26@github.com>

Continuing this review on a new PR (for jdk16). I have also updated the implementation to use VerifyVersionInfo.

Thanks,
Michael

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

Commit messages:
 - Test for Windows OS build >= 18362

Changes: https://git.openjdk.java.net/jdk16/pull/96/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=96&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259014
  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/96.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/96/head:pull/96

PR: https://git.openjdk.java.net/jdk16/pull/96

From aefimov at openjdk.java.net  Fri Jan  8 13:22:53 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 8 Jan 2021 13:22:53 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <GQZRQa0eTs-vhF2x1W-wqp3uBpxtR-evPQNPs4eiW9c=.8839784d-fccf-4d5d-ad47-af2c11aed30e@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <WfWVy9NtoNsW2S4UA74_eJAZTwspjzmzwO9mlIXCcCQ=.843478a1-bcd2-497a-9cea-2bd37fb833ad@github.com>
 <GQZRQa0eTs-vhF2x1W-wqp3uBpxtR-evPQNPs4eiW9c=.8839784d-fccf-4d5d-ad47-af2c11aed30e@github.com>
Message-ID: <pi8KRqBhZKpymYUR49AVIZn0NsgvUAPaNguuY_Iimsc=.29869180-4a40-435e-9be6-932de1e7b226@github.com>

On Sat, 19 Dec 2020 10:29:23 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Thank you for checking `HttpURLConnection` and `Socket`.
>> The latest version looks good to me.
>
> This issue is blocked by [8258657][1]. It should not be integrated until after 8258657 has been resolved. The JIRA issues have been linked up to reflect this.
> 
> [1]: https://bugs.openjdk.java.net/browse/JDK-8258657

[JDK-8258657](https://bugs.openjdk.java.net/browse/JDK-8258657) has been resolved. The changes reverted by [JDK-8258696](https://bugs.openjdk.java.net/browse/JDK-8258696) could also be re-applied to `HttpClientImpl` class.

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

PR: https://git.openjdk.java.net/jdk/pull/20

From janirutec at gmail.com  Fri Jan  8 13:45:45 2021
From: janirutec at gmail.com (JaniruTEC)
Date: Fri, 8 Jan 2021 14:45:45 +0100
Subject: 8030048: (fs) Support UserDefinedFileAttributeView/extended
 attributes on OS X / HFS+
In-Reply-To: <5c45f6bf-b27b-047b-2be7-9fa1f2a477b0@oracle.com>
References: <d209b1e3-f75a-6611-c1d8-dbc6f74f95b1@gmail.com>
 <5946d00b-0534-6313-4a4b-05a1a3330aff@oracle.com>
 <CAFMK=p3bQ-57CAoonAYOQrcm01-R_VtPFEpUsbqN3-vsyyGWoQ@mail.gmail.com>
 <5c45f6bf-b27b-047b-2be7-9fa1f2a477b0@oracle.com>
Message-ID: <e7716055-ad11-ecf1-4b73-82c76e2ac1ca@gmail.com>

On 26/11/2020 18:01, Alan Bateman wrote:

> At this time, the attributes views that are supported is configured in 
> BsdFileSystem but it's okay for MacOSXFileSystem to augment this. 
> There isn't any issue using unsafe here but the interface to these 
> APIs involved memory outside of the heap then we'll need to study it 
> closely to make sure that it is robust.
>
> -Alan

My employer wrote a proof of concept that heavily utilizes the existing 
linux code to create a BSD implementation, which can be found here: 
https://github.com/skymatic/jdk/tree/feature/macos-xattr

We have a few questions now:
- Since BSD and Linux share so much code, we believe deduplication could 
be a reasonable matter. Should this be part of this PR or a second one? 
Is deduplication even a matter you wish us to pursue?
- The Linux implementation doesn't utilize newer java features. Which is 
the latest java version the BSD Implementation should utilize features 
of? Should the Linux version be updated as well? How does backporting 
affect this decision?
- At what point in time should the PR be created? Is communication over 
Mail or over the PR preferred?

Thanks for your time!
- Dominik


From chegar at openjdk.java.net  Fri Jan  8 15:03:58 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 8 Jan 2021 15:03:58 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <pi8KRqBhZKpymYUR49AVIZn0NsgvUAPaNguuY_Iimsc=.29869180-4a40-435e-9be6-932de1e7b226@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <WfWVy9NtoNsW2S4UA74_eJAZTwspjzmzwO9mlIXCcCQ=.843478a1-bcd2-497a-9cea-2bd37fb833ad@github.com>
 <GQZRQa0eTs-vhF2x1W-wqp3uBpxtR-evPQNPs4eiW9c=.8839784d-fccf-4d5d-ad47-af2c11aed30e@github.com>
 <pi8KRqBhZKpymYUR49AVIZn0NsgvUAPaNguuY_Iimsc=.29869180-4a40-435e-9be6-932de1e7b226@github.com>
Message-ID: <wDuCc-RJWxdVNzjpTM9CODuGR3SDQUfiJK81NIUQVfk=.f2fc5c1a-8b72-4523-9fb7-2ee4c97b3f8b@github.com>

On Fri, 8 Jan 2021 13:20:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This issue is blocked by [8258657][1]. It should not be integrated until after 8258657 has been resolved. The JIRA issues have been linked up to reflect this.
>> 
>> [1]: https://bugs.openjdk.java.net/browse/JDK-8258657
>
> [JDK-8258657](https://bugs.openjdk.java.net/browse/JDK-8258657) has been resolved. The changes reverted by [JDK-8258696](https://bugs.openjdk.java.net/browse/JDK-8258696) could also be re-applied to `HttpClientImpl` class.

@AlekseiEfimov Yes please. Whatever is easier, include the changes to HttpClientImpl in this PR, or followup separately. Otherwise, I see no reason why this PR cannot proceed.

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

PR: https://git.openjdk.java.net/jdk/pull/20

From alanb at openjdk.java.net  Fri Jan  8 15:44:00 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 8 Jan 2021 15:44:00 GMT
Subject: [jdk16] RFR: 8259014: (so)
 ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress)
 will have unknown user and group owner (win)
In-Reply-To: <w5h1Mbc1FHH7J3cu8Oey87Iw-11YdbF7Fg_9rd4TpEM=.4e06c2e7-0306-4566-a15d-fef270185a26@github.com>
References: <w5h1Mbc1FHH7J3cu8Oey87Iw-11YdbF7Fg_9rd4TpEM=.4e06c2e7-0306-4566-a15d-fef270185a26@github.com>
Message-ID: <SOgB-xhJEkvijvAxFew6hwgY1ewY4nRfGqSsLhE4BP4=.d1c2130a-e12d-46a1-9556-72bfcf13ab09@github.com>

On Fri, 8 Jan 2021 12:02:47 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Continuing this review on a new PR (for jdk16). I have also updated the implementation to use VerifyVersionInfo.
> 
> Thanks,
> Michael

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/96

From michaelm at openjdk.java.net  Fri Jan  8 16:03:57 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 8 Jan 2021 16:03:57 GMT
Subject: [jdk16] Integrated: 8259014: (so)
 ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress)
 will have unknown user and group owner (win)
In-Reply-To: <w5h1Mbc1FHH7J3cu8Oey87Iw-11YdbF7Fg_9rd4TpEM=.4e06c2e7-0306-4566-a15d-fef270185a26@github.com>
References: <w5h1Mbc1FHH7J3cu8Oey87Iw-11YdbF7Fg_9rd4TpEM=.4e06c2e7-0306-4566-a15d-fef270185a26@github.com>
Message-ID: <TTW3n1FSRlow24nkm7yJniBfRZbrB6Ibs9utWn5Q-ms=.3095ec81-43ca-42cb-ad1d-77cd753475c1@github.com>

On Fri, 8 Jan 2021 12:02:47 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Continuing this review on a new PR (for jdk16). I have also updated the implementation to use VerifyVersionInfo.
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: fb68395d
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/fb68395d
Stats:     10 lines in 1 file changed: 9 ins; 0 del; 1 mod

8259014: (so) ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress) will have unknown user and group owner (win)

Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk16/pull/96

From github.com+471021+marschall at openjdk.java.net  Sat Jan  9 23:06:22 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Sat, 9 Jan 2021 23:06:22 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

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

  Add unit tests
  
  - add unit test for Reader#read(CharBuffer)
  - add unit test for InputStreamReader#reader(CharBuffer)
  - test with both on-heap and off-heap buffers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/8d405587..d247b637

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=02-03

  Stats: 170 lines in 2 files changed: 170 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915

PR: https://git.openjdk.java.net/jdk/pull/1915

From github.com+2996845+bokken at openjdk.java.net  Sun Jan 10 02:01:59 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Sun, 10 Jan 2021 02:01:59 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
Message-ID: <tEZQI1hwWbNe6n5aZmAJYWN2xpTqwntGtNNVTIsjQ5Q=.82cbeddb-8468-4b4f-a770-a25b9c5f5acf@github.com>

On Sat, 9 Jan 2021 23:06:22 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add unit tests
>   
>   - add unit test for Reader#read(CharBuffer)
>   - add unit test for InputStreamReader#reader(CharBuffer)
>   - test with both on-heap and off-heap buffers

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

> 196:         } else {
> 197:             int remaining = target.remaining();
> 198:             char cbuf[] = new char[Math.min(remaining, TRANSFER_BUFFER_SIZE)];

Would there be value in making this a (lazily created) member variable? That would allow a single instance to be reused. It seems likely that, if one call is made with a direct CharBuffer, subsequent calls will also be made with direct instances (probably same instance?).

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From Alan.Bateman at oracle.com  Sun Jan 10 14:46:36 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 10 Jan 2021 14:46:36 +0000
Subject: 8030048: (fs) Support UserDefinedFileAttributeView/extended
 attributes on OS X / HFS+
In-Reply-To: <FEA3A215-32FA-42B3-BA58-74D5D6CE48FE@gmail.com>
References: <d209b1e3-f75a-6611-c1d8-dbc6f74f95b1@gmail.com>
 <5946d00b-0534-6313-4a4b-05a1a3330aff@oracle.com>
 <CAFMK=p3bQ-57CAoonAYOQrcm01-R_VtPFEpUsbqN3-vsyyGWoQ@mail.gmail.com>
 <5c45f6bf-b27b-047b-2be7-9fa1f2a477b0@oracle.com>
 <e7716055-ad11-ecf1-4b73-82c76e2ac1ca@gmail.com>
 <FEA3A215-32FA-42B3-BA58-74D5D6CE48FE@gmail.com>
Message-ID: <ba0f5bd3-7cf9-51b0-090a-40982f590926@oracle.com>

On 08/01/2021 14:07, Sebastian Stenzel wrote:
> :
> If I may amend the list of questions:
>
> While the tier1 tests all passed, I am pretty sure that the most relevant test for this PR was not included: `tests/jdk/java/nio/file/attribute/UserDefinedAttributeView/Basic.java` Since we haven't dealt with jtreg before, can you give us any hint on how to execute one specific test individually?
>
The tests for this area are currently configured to run in tier2. 
Assuming you have run configure with the location of jtreg (I assume you 
have have if you are running the tier1 tests locally) then one way to 
run just these tests is:

make run-test TEST="jtreg:test/jdk/java/nio/file"

-Alan

From Alan.Bateman at oracle.com  Sun Jan 10 14:58:38 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 10 Jan 2021 14:58:38 +0000
Subject: 8030048: (fs) Support UserDefinedFileAttributeView/extended
 attributes on OS X / HFS+
In-Reply-To: <e7716055-ad11-ecf1-4b73-82c76e2ac1ca@gmail.com>
References: <d209b1e3-f75a-6611-c1d8-dbc6f74f95b1@gmail.com>
 <5946d00b-0534-6313-4a4b-05a1a3330aff@oracle.com>
 <CAFMK=p3bQ-57CAoonAYOQrcm01-R_VtPFEpUsbqN3-vsyyGWoQ@mail.gmail.com>
 <5c45f6bf-b27b-047b-2be7-9fa1f2a477b0@oracle.com>
 <e7716055-ad11-ecf1-4b73-82c76e2ac1ca@gmail.com>
Message-ID: <fc0cb61c-a6f6-b913-5ee8-e11faf7fd904@oracle.com>

On 08/01/2021 13:45, JaniruTEC wrote:
>
> My employer wrote a proof of concept that heavily utilizes the 
> existing linux code to create a BSD implementation, which can be found 
> here: 
> https://urldefense.com/v3/__https://github.com/skymatic/jdk/tree/feature/macos-xattr__;!!GqivPVa7Brio!L6gpaYGumU5fAqlD9-_hNfdJmKqmm7A-bNPr8wRolGyrMcK0m2CIYGz9g3TTKra8sg$ 
>
> We have a few questions now:
> - Since BSD and Linux share so much code, we believe deduplication 
> could be a reasonable matter. Should this be part of this PR or a 
> second one? Is deduplication even a matter you wish us to pursue?
> - The Linux implementation doesn't utilize newer java features. Which 
> is the latest java version the BSD Implementation should utilize 
> features of? Should the Linux version be updated as well? How does 
> backporting affect this decision?
> - At what point in time should the PR be created? Is communication 
> over Mail or over the PR preferred?
If this is mostly a clone of the implementation from src/java.base/linux 
then it may make sense to move it to src/java.base/unix and then have it 
conditionally compiled in on the platforms that support it. We haven't 
needed to do anything significant on that attribute view is a long time 
so modernizing make sense too. My personal preference is to have the 
changes be as easy to review as possible. If we can't see the diffs in 
the files change and/or webrev view then it will awkward to review. So 
if you can split into 2 or 3 patches then it might be easier. If the 
patches are small then starting with a PR is okay. If the changes are 
large then it's better to discuss and get agreement on the mailing lists 
before trying to get detailed reviews.

I don't think I understand your question about the BSD port as it is 
maintained in a downstream project. We just maintain the macOS port here.

-Alan

From sebastian.stenzel at gmail.com  Sun Jan 10 15:13:09 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Sun, 10 Jan 2021 16:13:09 +0100
Subject: 8030048: (fs) Support UserDefinedFileAttributeView/extended
 attributes on OS X / HFS+
In-Reply-To: <fc0cb61c-a6f6-b913-5ee8-e11faf7fd904@oracle.com>
References: <d209b1e3-f75a-6611-c1d8-dbc6f74f95b1@gmail.com>
 <5946d00b-0534-6313-4a4b-05a1a3330aff@oracle.com>
 <CAFMK=p3bQ-57CAoonAYOQrcm01-R_VtPFEpUsbqN3-vsyyGWoQ@mail.gmail.com>
 <5c45f6bf-b27b-047b-2be7-9fa1f2a477b0@oracle.com>
 <e7716055-ad11-ecf1-4b73-82c76e2ac1ca@gmail.com>
 <fc0cb61c-a6f6-b913-5ee8-e11faf7fd904@oracle.com>
Message-ID: <69C0443E-7291-4B7F-A425-FE48FF7AB6F5@gmail.com>


> On 10. Jan 2021, at 15:58, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 08/01/2021 13:45, JaniruTEC wrote:
>> 
>> My employer wrote a proof of concept that heavily utilizes the existing linux code to create a BSD implementation, which can be found here: https://urldefense.com/v3/__https://github.com/skymatic/jdk/tree/feature/macos-xattr__;!!GqivPVa7Brio!L6gpaYGumU5fAqlD9-_hNfdJmKqmm7A-bNPr8wRolGyrMcK0m2CIYGz9g3TTKra8sg$ 
>> We have a few questions now:
>> - Since BSD and Linux share so much code, we believe deduplication could be a reasonable matter. Should this be part of this PR or a second one? Is deduplication even a matter you wish us to pursue?
>> - The Linux implementation doesn't utilize newer java features. Which is the latest java version the BSD Implementation should utilize features of? Should the Linux version be updated as well? How does backporting affect this decision?
>> - At what point in time should the PR be created? Is communication over Mail or over the PR preferred?
> If this is mostly a clone of the implementation from src/java.base/linux then it may make sense to move it to src/java.base/unix and then have it conditionally compiled in on the platforms that support it. We haven't needed to do anything significant on that attribute view is a long time so modernizing make sense too. My personal preference is to have the changes be as easy to review as possible. If we can't see the diffs in the files change and/or webrev view then it will awkward to review. So if you can split into 2 or 3 patches then it might be easier. If the patches are small then starting with a PR is okay. If the changes are large then it's better to discuss and get agreement on the mailing lists before trying to get detailed reviews.
> 
> I don't think I understand your question about the BSD port as it is maintained in a downstream project. We just maintain the macOS port here.
> 
> -Alan


I agree that in order to easily follow what has changed, we should do two separate patches:

1. add macOS support and accept the fact that this is 90% duplicated code from Linux
2. deduplicate and modernize


Regarding the BSD confusion: MacOSXFileSystemProvider extends BsdFileSystemProvider. We have four system calls (fgetxattr, fsetxattr, fremovexattr, flistxattr), all of them not being macOS-specific, but rather inherited from the BSD-based XNU kernel. If you look up the man pages for any of them on macOS, you'll get the BSD man page.

That is why we thought it would be best to put the added code to the most generic place possible, which is (currently) the BsdFileSystemProvider. After dedup it will probably be UnixFileSystemProvider, however some distinctions will be required.


Tests look good btw:

   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/nio/file                         61    61     0     0  


Should we create a PR to proceed with the review? If so, what would be an appropriate name (like should it contain the bug id)?

Cheers,
Sebastian

From Alan.Bateman at oracle.com  Sun Jan 10 16:51:40 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 10 Jan 2021 16:51:40 +0000
Subject: 8030048: (fs) Support UserDefinedFileAttributeView/extended
 attributes on OS X / HFS+
In-Reply-To: <69C0443E-7291-4B7F-A425-FE48FF7AB6F5@gmail.com>
References: <d209b1e3-f75a-6611-c1d8-dbc6f74f95b1@gmail.com>
 <5946d00b-0534-6313-4a4b-05a1a3330aff@oracle.com>
 <CAFMK=p3bQ-57CAoonAYOQrcm01-R_VtPFEpUsbqN3-vsyyGWoQ@mail.gmail.com>
 <5c45f6bf-b27b-047b-2be7-9fa1f2a477b0@oracle.com>
 <e7716055-ad11-ecf1-4b73-82c76e2ac1ca@gmail.com>
 <fc0cb61c-a6f6-b913-5ee8-e11faf7fd904@oracle.com>
 <69C0443E-7291-4B7F-A425-FE48FF7AB6F5@gmail.com>
Message-ID: <565a8e3e-9a9d-bb47-9d7a-bbb17c632ee9@oracle.com>

On 10/01/2021 15:13, Sebastian Stenzel wrote:
> :
> I agree that in order to easily follow what has changed, we should do two separate patches:
>
> 1. add macOS support and accept the fact that this is 90% duplicated code from Linux
> 2. deduplicate and modernize
That's fine. You can use JDK-8030048 for the PR to add the 
implementation for macOS. We can create a second issue to merge the 
implementations.


> Regarding the BSD confusion: MacOSXFileSystemProvider extends BsdFileSystemProvider. We have four system calls (fgetxattr, fsetxattr, fremovexattr, flistxattr), all of them not being macOS-specific, but rather inherited from the BSD-based XNU kernel. If you look up the man pages for any of them on macOS, you'll get the BSD man page.
Sure, there is a bit of history issue from JDK 7u4 then the macOS port 
was added. It was initially based on the BSD port although the BSD port 
was still maintained in down stream projects.


> That is why we thought it would be best to put the added code to the most generic place possible, which is (currently) the BsdFileSystemProvider. After dedup it will probably be UnixFileSystemProvider, however some distinctions will be required.
Yes, I'm sure there will be subtle differences and some conditional 
inclusion by the build too.

-Alan.

From sebastian.stenzel at gmail.com  Mon Jan 11 09:07:33 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Mon, 11 Jan 2021 10:07:33 +0100
Subject: 8030048: (fs) Support UserDefinedFileAttributeView/extended
 attributes on OS X / HFS+
In-Reply-To: <565a8e3e-9a9d-bb47-9d7a-bbb17c632ee9@oracle.com>
References: <d209b1e3-f75a-6611-c1d8-dbc6f74f95b1@gmail.com>
 <5946d00b-0534-6313-4a4b-05a1a3330aff@oracle.com>
 <CAFMK=p3bQ-57CAoonAYOQrcm01-R_VtPFEpUsbqN3-vsyyGWoQ@mail.gmail.com>
 <5c45f6bf-b27b-047b-2be7-9fa1f2a477b0@oracle.com>
 <e7716055-ad11-ecf1-4b73-82c76e2ac1ca@gmail.com>
 <fc0cb61c-a6f6-b913-5ee8-e11faf7fd904@oracle.com>
 <69C0443E-7291-4B7F-A425-FE48FF7AB6F5@gmail.com>
 <565a8e3e-9a9d-bb47-9d7a-bbb17c632ee9@oracle.com>
Message-ID: <61B15B7C-49EA-43BC-93CD-D43AB5C90D9A@gmail.com>


> On 10. Jan 2021, at 17:51, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> That's fine. You can use JDK-8030048 for the PR to add the implementation for macOS. [...]

Great, I've created the PR (2017), but am still waiting for the OCA check... Don't know how long this usually takes and I don't understand how it will get mapped to the GH username. Is there anything I can do to speed this up?

From aefimov at openjdk.java.net  Mon Jan 11 16:59:55 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 11 Jan 2021 16:59:55 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <ATU6wTDVsNS7sHv3Cz7EMSofyi37vK_s7cjd4fh8rRI=.cc6c3ffc-ece4-4cdd-af23-cb198293c9c0@github.com>

On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Hi @turbanoff,
This PR is ready for integration - `JDK-8258657` has been resolved.
You can proceed with issuing `integrate` bot command. Then I will `sponsor` it.
But before that, I would like to ask if you would like to take on board the changes to `HttpClientImpl`? Alternatively, I can follow it up separately and reapply the backed-out change under different bugID.

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

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+741251+turbanoff at openjdk.java.net  Mon Jan 11 17:14:55 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Jan 2021 17:14:55 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <ATU6wTDVsNS7sHv3Cz7EMSofyi37vK_s7cjd4fh8rRI=.cc6c3ffc-ece4-4cdd-af23-cb198293c9c0@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ATU6wTDVsNS7sHv3Cz7EMSofyi37vK_s7cjd4fh8rRI=.cc6c3ffc-ece4-4cdd-af23-cb198293c9c0@github.com>
Message-ID: <bMHh1BwKaTYbdmAQPLR6LJUgRtff7l3qY8-4R94iQj8=.a02498a0-be70-41a6-85b1-340e41d4393a@github.com>

On Mon, 11 Jan 2021 16:57:00 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Hi @turbanoff,
> This PR is ready for integration - `JDK-8258657` has been resolved.
> You can proceed with issuing `integrate` bot command. Then I will `sponsor` it.
> But before that, I would like to ask if you would like to take on board the changes to `HttpClientImpl`? Alternatively, I can follow it up separately and reapply the backed-out change under different bugID.

@AlekseiEfimov `HttpClientImpl` is not in `java.base` module. So I think it's better to not touch it under this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+1204330+overheadhunter at openjdk.java.net  Mon Jan 11 21:33:08 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Mon, 11 Jan 2021 21:33:08 GMT
Subject: RFR: JDK-8030048: (fs) Support UserDefinedFileAttributeView/extended
 attributes on OS X / HFS+
Message-ID: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>

This adds support for UserDefinedFileAttributeView on macOS 10.4 and newer.

While the main audience for this will probably be macOS users, the relevant changes take place in (mostly existing) classes carrying BSD in their names as none of this is really macOS-specific.

Code is mostly copied from the Linux implementation except for three differences:
1. max length for attribute names is 127 bytes
2. we know for sure that APFS and HFS+ support extended attributes, therefore we [simply return `true`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L114-L118) from `supportsFileAttributeView(UserDefinedFileAttributeView.class)` for these two FS types, while for all other types support is determined experimentally in [`isExtendedAttributesEnabled(...)`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L83-L100)
3. For the aforementioned check the new `UnixConstants.ENOATTR` is added, which [seems to be macOS and BSD-specific](https://mail-index.netbsd.org/tech-kern/2012/04/30/msg013090.html).

As discussed in the mailing list, for ease of tracking changes it is not a goal of this patch to modernize the existing Linux implementation, nor to deduplicate anything.

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

Commit messages:
 - implemented supportsFileAttributeView
 - Added UserDefinedAttributeView support
 - typo
 - Added JNI methods for fgetxattr/fsetxattr/fremovexattr/flistxattr for BSD

Changes: https://git.openjdk.java.net/jdk/pull/2017/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2017&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8030048
  Stats: 206 lines in 7 files changed: 200 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2017/head:pull/2017

PR: https://git.openjdk.java.net/jdk/pull/2017

From jwilhelm at openjdk.java.net  Mon Jan 11 22:10:14 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 11 Jan 2021 22:10:14 GMT
Subject: RFR: Merge jdk16
Message-ID: <puz-WDoJfDxb8F14PsmiARZzYuRXqexRZMCMReqae-0=.1fa3cb70-fa3c-4953-9448-f64b91dcd7fd@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing
 - 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl
 - 8259043: More Zero architectures need linkage with libatomic
 - 8259429: Update reference to README.md
 - 8259014: (so) ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress) will have unknown user and group owner (win)

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2040/files
  Stats: 140 lines in 12 files changed: 117 ins; 2 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2040.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2040/head:pull/2040

PR: https://git.openjdk.java.net/jdk/pull/2040

From aefimov at openjdk.java.net  Mon Jan 11 23:47:07 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 11 Jan 2021 23:47:07 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <AerlTMOZX29koszPtGYArb_6xjd2wjmRA8zhJhyzmAI=.08b971df-9c15-4d46-944d-b2bd08e5cdf8@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ATU6wTDVsNS7sHv3Cz7EMSofyi37vK_s7cjd4fh8rRI=.cc6c3ffc-ece4-4cdd-af23-cb198293c9c0@github.com>
 <bMHh1BwKaTYbdmAQPLR6LJUgRtff7l3qY8-4R94iQj8=.a02498a0-be70-41a6-85b1-340e41d4393a@github.com>
 <AerlTMOZX29koszPtGYArb_6xjd2wjmRA8zhJhyzmAI=.08b971df-9c15-4d46-944d-b2bd08e5cdf8@github.com>
Message-ID: <1sPtWhqRwT66UsTxWsfUtV05qkEufrEf4wmoKww3sdI=.f6cb56c4-3417-4b5e-ace3-4467013bb0cc@github.com>

On Mon, 11 Jan 2021 23:29:53 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> @AlekseiEfimov `HttpClientImpl` is not in `java.base` module. So I think it's better to not touch it under this PR.
>
> To double check that docs build will be stable after integration the following actions have been performed:
> - The pull request branch was locally synced-up with the latest changes from `master` (`JDK-8258657` is part of them)
> - Verified that local  `docs-reference-api-javadoc` build completes successfully

sponsor

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

PR: https://git.openjdk.java.net/jdk/pull/20

From aefimov at openjdk.java.net  Mon Jan 11 23:47:07 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 11 Jan 2021 23:47:07 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <bMHh1BwKaTYbdmAQPLR6LJUgRtff7l3qY8-4R94iQj8=.a02498a0-be70-41a6-85b1-340e41d4393a@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ATU6wTDVsNS7sHv3Cz7EMSofyi37vK_s7cjd4fh8rRI=.cc6c3ffc-ece4-4cdd-af23-cb198293c9c0@github.com>
 <bMHh1BwKaTYbdmAQPLR6LJUgRtff7l3qY8-4R94iQj8=.a02498a0-be70-41a6-85b1-340e41d4393a@github.com>
Message-ID: <AerlTMOZX29koszPtGYArb_6xjd2wjmRA8zhJhyzmAI=.08b971df-9c15-4d46-944d-b2bd08e5cdf8@github.com>

On Mon, 11 Jan 2021 17:12:24 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Hi @turbanoff,
>> This PR is ready for integration - `JDK-8258657` has been resolved.
>> You can proceed with issuing `integrate` bot command. Then I will `sponsor` it.
>> But before that, I would like to ask if you would like to take on board the changes to `HttpClientImpl`? Alternatively, I can follow it up separately and reapply the backed-out change under different bugID.
>
> @AlekseiEfimov `HttpClientImpl` is not in `java.base` module. So I think it's better to not touch it under this PR.

To double check that docs build will be stable after integration the following actions have been performed:
- The pull request branch was locally synced-up with the latest changes from `master` (`JDK-8258657` is part of them)
- Verified that local  `docs-reference-api-javadoc` build completes successfully

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

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+741251+turbanoff at openjdk.java.net  Mon Jan 11 23:47:08 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Jan 2021 23:47:08 GMT
Subject: Integrated: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <DBeZIYQZh5XFkbxNiqJVAVDEKiWi2G2xhwzE-GVhFaQ=.36706ba8-6654-4942-9ef5-510f3f7d11e8@github.com>

On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

This pull request has now been integrated.

Changeset: 022bc9f0
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/022bc9f0
Stats:     82 lines in 22 files changed: 1 ins; 13 del; 68 mod

8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Reviewed-by: chegar, aefimov

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

PR: https://git.openjdk.java.net/jdk/pull/20

From jwilhelm at openjdk.java.net  Tue Jan 12 00:59:20 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 12 Jan 2021 00:59:20 GMT
Subject: RFR: Merge jdk16 [v2]
In-Reply-To: <puz-WDoJfDxb8F14PsmiARZzYuRXqexRZMCMReqae-0=.1fa3cb70-fa3c-4953-9448-f64b91dcd7fd@github.com>
References: <puz-WDoJfDxb8F14PsmiARZzYuRXqexRZMCMReqae-0=.1fa3cb70-fa3c-4953-9448-f64b91dcd7fd@github.com>
Message-ID: <ncsIT8L7wP2FB8E1hXdn4kf9SCDNPwwzJxUW5F6OAeg=.ab6af386-ed70-47c5-acac-cb3c41928663@github.com>

> Forwardport JDK 16 -> JDK 17

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

  Merge

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2040/files
  - new: https://git.openjdk.java.net/jdk/pull/2040/files/e55da33b..69dad8ed

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2040

From jwilhelm at openjdk.java.net  Tue Jan 12 01:10:59 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 12 Jan 2021 01:10:59 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <puz-WDoJfDxb8F14PsmiARZzYuRXqexRZMCMReqae-0=.1fa3cb70-fa3c-4953-9448-f64b91dcd7fd@github.com>
References: <puz-WDoJfDxb8F14PsmiARZzYuRXqexRZMCMReqae-0=.1fa3cb70-fa3c-4953-9448-f64b91dcd7fd@github.com>
Message-ID: <D5Zt2DnTVy1p54aids2HeMuXTor4ubsgD56B5Mq7q-8=.ffac5c11-9979-46dc-b78e-9f4ba2c85b39@github.com>

On Mon, 11 Jan 2021 22:04:16 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: b378f54d
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b378f54d
Stats:     139 lines in 12 files changed: 116 ins; 2 del; 21 mod

Merge

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

PR: https://git.openjdk.java.net/jdk/pull/2040

From ccleary at openjdk.java.net  Tue Jan 12 19:53:04 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 12 Jan 2021 19:53:04 GMT
Subject: RFR: 8257212: (bf spec) Clarify byte order of the buffer returned by
 CharBuffer.subsequence(int, int)
Message-ID: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>

Specification for CharBuffer::subSequence was missing clarification on the byte order of the returned CharBuffer. The returned order will always be the same as that of the original buffer. For example, subSequence() called on a CharBuffer with Little-Endian Byte Order will return a CharBuffer of Little-Endian Order. The specification has been changed to reflect this.

In addition to this, some additional testing was added to improve test coverage of this behavior. Testing for the Byte Order of different types of Buffer is generated via the template Order-X.java.template which serves to verify the original Byte Order of a Buffer and subsequently verify that the same Byte Order is present after operations such as CharBuffer::subSequence

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

Commit messages:
 - 8257212: (bf spec) Clarify byte order of the buffer returned by CharBuffer.subsequence(int,int)

Changes: https://git.openjdk.java.net/jdk/pull/2049/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2049&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257212
  Stats: 186 lines in 8 files changed: 183 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2049/head:pull/2049

PR: https://git.openjdk.java.net/jdk/pull/2049

From ccleary at openjdk.java.net  Tue Jan 12 19:53:04 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 12 Jan 2021 19:53:04 GMT
Subject: RFR: 8257212: (bf spec) Clarify byte order of the buffer returned
 by CharBuffer.subsequence(int, int)
In-Reply-To: <_IuOg2hoA4AsfMvQWrYh73kgwSclfSrVYthP5Ekz7e0=.b3b234a2-3ee4-40d0-87f8-853078cd1219@github.com>
References: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
 <_IuOg2hoA4AsfMvQWrYh73kgwSclfSrVYthP5Ekz7e0=.b3b234a2-3ee4-40d0-87f8-853078cd1219@github.com>
Message-ID: <OnBO6JckTCv6IcJWN60mHh_6swIm7oZBSs41lED1w5Q=.4910d070-ed4c-423e-8236-60405e01d265@github.com>

On Tue, 12 Jan 2021 14:29:28 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Specification for CharBuffer::subSequence was missing clarification on the byte order of the returned CharBuffer. The returned order will always be the same as that of the original buffer. For example, subSequence() called on a CharBuffer with Little-Endian Byte Order will return a CharBuffer of Little-Endian Order. The specification has been changed to reflect this.
>> 
>> In addition to this, some additional testing was added to improve test coverage of this behavior. Testing for the Byte Order of different types of Buffer is generated via the template Order-X.java.template which serves to verify the original Byte Order of a Buffer and subsequently verify that the same Byte Order is present after operations such as CharBuffer::subSequence
>
> Marked as reviewed by chegar (Reviewer).

CDR is filed: [https://bugs.openjdk.java.net/browse/JDK-8259638](https://bugs.openjdk.java.net/browse/JDK-8259638)

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

PR: https://git.openjdk.java.net/jdk/pull/2049

From chegar at openjdk.java.net  Tue Jan 12 19:53:04 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 12 Jan 2021 19:53:04 GMT
Subject: RFR: 8257212: (bf spec) Clarify byte order of the buffer returned
 by CharBuffer.subsequence(int, int)
In-Reply-To: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
References: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
Message-ID: <_IuOg2hoA4AsfMvQWrYh73kgwSclfSrVYthP5Ekz7e0=.b3b234a2-3ee4-40d0-87f8-853078cd1219@github.com>

On Tue, 12 Jan 2021 13:47:54 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> Specification for CharBuffer::subSequence was missing clarification on the byte order of the returned CharBuffer. The returned order will always be the same as that of the original buffer. For example, subSequence() called on a CharBuffer with Little-Endian Byte Order will return a CharBuffer of Little-Endian Order. The specification has been changed to reflect this.
> 
> In addition to this, some additional testing was added to improve test coverage of this behavior. Testing for the Byte Order of different types of Buffer is generated via the template Order-X.java.template which serves to verify the original Byte Order of a Buffer and subsequently verify that the same Byte Order is present after operations such as CharBuffer::subSequence

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2049

From bpb at openjdk.java.net  Tue Jan 12 19:59:56 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 12 Jan 2021 19:59:56 GMT
Subject: RFR: 8257212: (bf spec) Clarify byte order of the buffer returned
 by CharBuffer.subsequence(int, int)
In-Reply-To: <OnBO6JckTCv6IcJWN60mHh_6swIm7oZBSs41lED1w5Q=.4910d070-ed4c-423e-8236-60405e01d265@github.com>
References: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
 <_IuOg2hoA4AsfMvQWrYh73kgwSclfSrVYthP5Ekz7e0=.b3b234a2-3ee4-40d0-87f8-853078cd1219@github.com>
 <OnBO6JckTCv6IcJWN60mHh_6swIm7oZBSs41lED1w5Q=.4910d070-ed4c-423e-8236-60405e01d265@github.com>
Message-ID: <obj-ygia00yjVN1_RUYG_rexyjvZOVSKfMFREvAGYYI=.a494ffec-7ed4-4069-b87a-083dccea3ad8@github.com>

On Tue, 12 Jan 2021 19:49:55 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Marked as reviewed by chegar (Reviewer).
>
> CDR is filed: [https://bugs.openjdk.java.net/browse/JDK-8259638](https://bugs.openjdk.java.net/browse/JDK-8259638)

In X-Buffer.java.template, s/2020/2021/ in the copyright year; in Order-X.java.template add 2021 as second copyright year.

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

PR: https://git.openjdk.java.net/jdk/pull/2049

From ccleary at openjdk.java.net  Wed Jan 13 10:08:14 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 13 Jan 2021 10:08:14 GMT
Subject: RFR: 8257212: (bf spec) Clarify byte order of the buffer returned
 by CharBuffer.subsequence(int, int) [v2]
In-Reply-To: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
References: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
Message-ID: <nyphQxiG1SdiIufG2EohSAwbu7gHfYxOyNr-08HoFtQ=.f793f7db-a16b-4ef8-8073-b98b7c67fa7b@github.com>

> Specification for CharBuffer::subSequence was missing clarification on the byte order of the returned CharBuffer. The returned order will always be the same as that of the original buffer. For example, subSequence() called on a CharBuffer with Little-Endian Byte Order will return a CharBuffer of Little-Endian Order. The specification has been changed to reflect this.
> 
> In addition to this, some additional testing was added to improve test coverage of this behavior. Testing for the Byte Order of different types of Buffer is generated via the template Order-X.java.template which serves to verify the original Byte Order of a Buffer and subsequently verify that the same Byte Order is present after operations such as CharBuffer::subSequence

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

  8257212: Updated copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2049/files
  - new: https://git.openjdk.java.net/jdk/pull/2049/files/f194a7d1..4f90a205

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2049&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2049&range=00-01

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2049/head:pull/2049

PR: https://git.openjdk.java.net/jdk/pull/2049

From ccleary at openjdk.java.net  Wed Jan 13 10:10:57 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 13 Jan 2021 10:10:57 GMT
Subject: RFR: 8257212: (bf spec) Clarify byte order of the buffer returned
 by CharBuffer.subsequence(int, int) [v2]
In-Reply-To: <obj-ygia00yjVN1_RUYG_rexyjvZOVSKfMFREvAGYYI=.a494ffec-7ed4-4069-b87a-083dccea3ad8@github.com>
References: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
 <_IuOg2hoA4AsfMvQWrYh73kgwSclfSrVYthP5Ekz7e0=.b3b234a2-3ee4-40d0-87f8-853078cd1219@github.com>
 <OnBO6JckTCv6IcJWN60mHh_6swIm7oZBSs41lED1w5Q=.4910d070-ed4c-423e-8236-60405e01d265@github.com>
 <obj-ygia00yjVN1_RUYG_rexyjvZOVSKfMFREvAGYYI=.a494ffec-7ed4-4069-b87a-083dccea3ad8@github.com>
Message-ID: <c4ni6CnAGwk2wVI8PmQ7_ObbRpOm5e0mp81Em47bx7g=.a6c303cd-994a-4721-bd84-daefbb6a8b77@github.com>

On Tue, 12 Jan 2021 19:57:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In X-Buffer.java.template, s/2020/2021/ in the copyright year; in Order-X.java.template add 2021 as second copyright year.

2021 is now added to all copyright notices... classic start of the year mistake!

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

PR: https://git.openjdk.java.net/jdk/pull/2049

From alanb at openjdk.java.net  Wed Jan 13 12:19:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Jan 2021 12:19:57 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+
In-Reply-To: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
Message-ID: <R4j-BIsYVMEU33ktQvjJNGDMfnRRtkIGK1MGgXbdm9w=.5829065d-9ca6-499c-8f49-5a05a0fdd8f1@github.com>

On Sun, 10 Jan 2021 17:17:16 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

> This adds support for UserDefinedFileAttributeView on macOS 10.4 and newer.
> 
> While the main audience for this will probably be macOS users, the relevant changes take place in (mostly existing) classes carrying BSD in their names as none of this is really macOS-specific.
> 
> Code is mostly copied from the Linux implementation except for three differences:
> 1. max length for attribute names is 127 bytes
> 2. we know for sure that APFS and HFS+ support extended attributes, therefore we [simply return `true`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L114-L118) from `supportsFileAttributeView(UserDefinedFileAttributeView.class)` for these two FS types, while for all other types support is determined experimentally in [`isExtendedAttributesEnabled(...)`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L83-L100)
> 3. For the aforementioned check the new `UnixConstants.ENOATTR` is added, which [seems to be macOS and BSD-specific](https://mail-index.netbsd.org/tech-kern/2012/04/30/msg013090.html).
> 
> As discussed in the mailing list, for ease of tracking changes it is not a goal of this patch to modernize the existing Linux implementation, nor to deduplicate anything.

src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 104:

> 102:     @Override
> 103:     public boolean supportsFileAttributeView(Class<? extends FileAttributeView> type) {
> 104:         // support DosFileAttributeView and UserDefinedAttributeView if extended

A minor point here is that comment carrier over from the Linux implementation isn't quite right here as the BSD version doesn't support the "dos" attribute view.

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

PR: https://git.openjdk.java.net/jdk/pull/2017

From github.com+1204330+overheadhunter at openjdk.java.net  Wed Jan 13 12:35:25 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 13 Jan 2021 12:35:25 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+ [v2]
In-Reply-To: <R4j-BIsYVMEU33ktQvjJNGDMfnRRtkIGK1MGgXbdm9w=.5829065d-9ca6-499c-8f49-5a05a0fdd8f1@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
 <R4j-BIsYVMEU33ktQvjJNGDMfnRRtkIGK1MGgXbdm9w=.5829065d-9ca6-499c-8f49-5a05a0fdd8f1@github.com>
Message-ID: <e-ajZAGh5EisU-9gGkSsWISUsZNGuNayG8vDI7WLaP4=.4b600fd3-4837-4004-8ea4-8a8dccac1407@github.com>

On Wed, 13 Jan 2021 12:17:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed comment that was copy-pasted from LinuxFileStore
>
> src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 104:
> 
>> 102:     @Override
>> 103:     public boolean supportsFileAttributeView(Class<? extends FileAttributeView> type) {
>> 104:         // support DosFileAttributeView and UserDefinedAttributeView if extended
> 
> A minor point here is that comment carrier over from the Linux implementation isn't quite right here as the BSD version doesn't support the "dos" attribute view.

resolved in 5d00aa6

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

PR: https://git.openjdk.java.net/jdk/pull/2017

From github.com+1204330+overheadhunter at openjdk.java.net  Wed Jan 13 12:35:24 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 13 Jan 2021 12:35:24 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+ [v2]
In-Reply-To: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
Message-ID: <x05Eg-k6HM0qH2llK1fvyZPv5W7INfTR0qW9zF7jT0I=.c79db9d3-c026-45bd-9fbd-168061bcf9fc@github.com>

> This adds support for UserDefinedFileAttributeView on macOS 10.4 and newer.
> 
> While the main audience for this will probably be macOS users, the relevant changes take place in (mostly existing) classes carrying BSD in their names as none of this is really macOS-specific.
> 
> Code is mostly copied from the Linux implementation except for three differences:
> 1. max length for attribute names is 127 bytes
> 2. we know for sure that APFS and HFS+ support extended attributes, therefore we [simply return `true`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L114-L118) from `supportsFileAttributeView(UserDefinedFileAttributeView.class)` for these two FS types, while for all other types support is determined experimentally in [`isExtendedAttributesEnabled(...)`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L83-L100)
> 3. For the aforementioned check the new `UnixConstants.ENOATTR` is added, which [seems to be macOS and BSD-specific](https://mail-index.netbsd.org/tech-kern/2012/04/30/msg013090.html).
> 
> As discussed in the mailing list, for ease of tracking changes it is not a goal of this patch to modernize the existing Linux implementation, nor to deduplicate anything.

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

  fixed comment that was copy-pasted from LinuxFileStore

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2017/files
  - new: https://git.openjdk.java.net/jdk/pull/2017/files/7a3619df..5d00aa62

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2017&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2017&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2017

From alanb at openjdk.java.net  Wed Jan 13 12:50:00 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Jan 2021 12:50:00 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+
In-Reply-To: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
Message-ID: <A990jX69OG32DmiVc50hO6d7QEcWxr5QWGjbtBvKpmg=.4bd69a2e-8734-4075-8247-0a9ed3e00f5c@github.com>

On Sun, 10 Jan 2021 17:17:16 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

> This adds support for UserDefinedFileAttributeView on macOS 10.4 and newer.
> 
> While the main audience for this will probably be macOS users, the relevant changes take place in (mostly existing) classes carrying BSD in their names as none of this is really macOS-specific.
> 
> Code is mostly copied from the Linux implementation except for three differences:
> 1. max length for attribute names is 127 bytes
> 2. we know for sure that APFS and HFS+ support extended attributes, therefore we [simply return `true`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L114-L118) from `supportsFileAttributeView(UserDefinedFileAttributeView.class)` for these two FS types, while for all other types support is determined experimentally in [`isExtendedAttributesEnabled(...)`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L83-L100)
> 3. For the aforementioned check the new `UnixConstants.ENOATTR` is added, which [seems to be macOS and BSD-specific](https://mail-index.netbsd.org/tech-kern/2012/04/30/msg013090.html).
> 
> As discussed in the mailing list, for ease of tracking changes it is not a goal of this patch to modernize the existing Linux implementation, nor to deduplicate anything.

Overall, this looks quite good and is easy to review.

I think the additions to BsdNativeDispatcher. will need a round or two of cleanup. They comments about XATTR_NOFOLLOW and other options documented in the man pages are a bit distracting. Also the style and excessive long lines aren't consistent with the existing code (and UnixNativeDispatcher).

One thing that we need to decide is whether the additional parameters (position, options) are exposed by BsdNativeDispatcher or not. I think I agree with your approach to have the signature match the methods in LinuxNativeDispatcher as that will make it easier to merge the two implementations later.




The comments that XATTR_NOFOLLOW is not applicable and other options not used is distracting and can be removed.

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

PR: https://git.openjdk.java.net/jdk/pull/2017

From github.com+1204330+overheadhunter at openjdk.java.net  Wed Jan 13 13:02:09 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 13 Jan 2021 13:02:09 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+
In-Reply-To: <A990jX69OG32DmiVc50hO6d7QEcWxr5QWGjbtBvKpmg=.4bd69a2e-8734-4075-8247-0a9ed3e00f5c@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
 <A990jX69OG32DmiVc50hO6d7QEcWxr5QWGjbtBvKpmg=.4bd69a2e-8734-4075-8247-0a9ed3e00f5c@github.com>
Message-ID: <VqY8DiTn-zadNA9jyu_Q894X7eAfDAYCAr6FA2QXokU=.4b65bf1d-94b3-40ec-913f-f3f5738ce631@github.com>

On Wed, 13 Jan 2021 12:46:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One thing that we need to decide is whether the additional parameters (position, options) are exposed by BsdNativeDispatcher or not. I think I agree with your approach to have the signature match the methods in LinuxNativeDispatcher as that will make it easier to merge the two implementations later.

Just to discuss all options, we could as well hide both params from Java entirely (set them inside of `BsdNativeDispatcher.c`)

> The comments that XATTR_NOFOLLOW is not applicable and other options not used is distracting and can be removed.

Sure, but maybe it should be documented _somewhere_ that none of the flags are required for this use case? Or do you think it is reasonable to assume that anyone stumbling upon this code will just look up the system calls' documentation to see what flags might have been possible?

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

PR: https://git.openjdk.java.net/jdk/pull/2017

From chegar at openjdk.java.net  Wed Jan 13 14:46:03 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 13 Jan 2021 14:46:03 GMT
Subject: RFR: 8257212: (bf spec) Clarify byte order of the buffer returned
 by CharBuffer.subsequence(int, int) [v2]
In-Reply-To: <nyphQxiG1SdiIufG2EohSAwbu7gHfYxOyNr-08HoFtQ=.f793f7db-a16b-4ef8-8073-b98b7c67fa7b@github.com>
References: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
 <nyphQxiG1SdiIufG2EohSAwbu7gHfYxOyNr-08HoFtQ=.f793f7db-a16b-4ef8-8073-b98b7c67fa7b@github.com>
Message-ID: <k0Tf3-z-N64vNNIYgi0a1Nqmv9tIz40UxHNz3QUr9O4=.ce8097e3-8bd4-4872-812c-e612395b5bcb@github.com>

On Wed, 13 Jan 2021 10:08:14 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Specification for CharBuffer::subSequence was missing clarification on the byte order of the returned CharBuffer. The returned order will always be the same as that of the original buffer. For example, subSequence() called on a CharBuffer with Little-Endian Byte Order will return a CharBuffer of Little-Endian Order. The specification has been changed to reflect this.
>> 
>> In addition to this, some additional testing was added to improve test coverage of this behavior. Testing for the Byte Order of different types of Buffer is generated via the template Order-X.java.template which serves to verify the original Byte Order of a Buffer and subsequently verify that the same Byte Order is present after operations such as CharBuffer::subSequence
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8259638
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8257212: Updated copyright year

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2049

From daniel.fuchs at oracle.com  Wed Jan 13 16:50:37 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Jan 2021 16:50:37 +0000
Subject: Difference in encoding semantics of URI returned by File.toURI
 and Path.toUri representing the same file
In-Reply-To: <3cd8d31d-1640-a855-4ba2-bf05be8adfe0@gmail.com>
References: <3cd8d31d-1640-a855-4ba2-bf05be8adfe0@gmail.com>
Message-ID: <08edf854-6414-800f-4fa4-2f06d234e6a6@oracle.com>

Hi Jaikiran,

java.net.URI doesn't require encoding non ascii characters, but
calling URI.toASCIIString() will ensure that they get encoded.

The two URIs, with non ASCII characters encoded or not encoded,
should be equivalent.

On 18/12/2020 04:50, Jaikiran Pai wrote:
> 
> URI from Paths.get().toUri() API /private/tmp/delme/foob?r ---> 
> file:///private/tmp/delme/fooba%CC%83r/

This looks like what you would obtain by calling URI.toASCIIString(),
except it's not exactly the same:

URI.create("file:///private/tmp/delme/foob?r/").toASCIIString()
---> file:///private/tmp/delme/foob%C3%A3r/

One form ("%C3%A3") is the UTF-8 encoding of the "?" unicode
character (U+00E3);
The other form ("a%80%83") is the combination of lower case "a"
followed by the combining "~" character ("a" + U+0303) which is another
way of encoding the "?" glyph in Unicode.

This is because URI.toASCIIString() uses NFC before encoding the UTF-8
sequence representing "?". Obviously Path.toURI() does not do that.
It's not clear to me whether NFC should be applied - or what would be
the consequences of applying NFC there (or not).

Both encodings seems to be working - if you feed the encoded string
to new URL(string).openConnection();

> URI from File.toPath().toUri() API /private/tmp/delme/foob?r ---> 
> file:///private/tmp/delme/fooba%CC%83r/
> URI from File.toURI() API /private/tmp/delme/foob?r ---> 
> file:/private/tmp/delme/foob?r/

best regards,

-- daniel

From bpb at openjdk.java.net  Wed Jan 13 17:09:05 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 13 Jan 2021 17:09:05 GMT
Subject: RFR: 8257212: (bf spec) Clarify byte order of the buffer returned
 by CharBuffer.subsequence(int, int) [v2]
In-Reply-To: <nyphQxiG1SdiIufG2EohSAwbu7gHfYxOyNr-08HoFtQ=.f793f7db-a16b-4ef8-8073-b98b7c67fa7b@github.com>
References: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
 <nyphQxiG1SdiIufG2EohSAwbu7gHfYxOyNr-08HoFtQ=.f793f7db-a16b-4ef8-8073-b98b7c67fa7b@github.com>
Message-ID: <Rh8-7SbicLxzBXWhY8q7ifiUxkG23DBKBv8_P5jJWEg=.3bee6b55-f968-4032-8858-a2c5e8e97af1@github.com>

On Wed, 13 Jan 2021 10:08:14 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Specification for CharBuffer::subSequence was missing clarification on the byte order of the returned CharBuffer. The returned order will always be the same as that of the original buffer. For example, subSequence() called on a CharBuffer with Little-Endian Byte Order will return a CharBuffer of Little-Endian Order. The specification has been changed to reflect this.
>> 
>> In addition to this, some additional testing was added to improve test coverage of this behavior. Testing for the Byte Order of different types of Buffer is generated via the template Order-X.java.template which serves to verify the original Byte Order of a Buffer and subsequently verify that the same Byte Order is present after operations such as CharBuffer::subSequence
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8259638
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8257212: Updated copyright year

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2049

From sebastian.stenzel at gmail.com  Wed Jan 13 18:45:29 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Wed, 13 Jan 2021 19:45:29 +0100
Subject: Difference in encoding semantics of URI returned by File.toURI
 and Path.toUri representing the same file
In-Reply-To: <08edf854-6414-800f-4fa4-2f06d234e6a6@oracle.com>
References: <3cd8d31d-1640-a855-4ba2-bf05be8adfe0@gmail.com>
 <08edf854-6414-800f-4fa4-2f06d234e6a6@oracle.com>
Message-ID: <9B159D6D-8AF4-414C-A86A-ACFD34D67288@gmail.com>


> On 13. Jan 2021, at 17:50, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> [...]
> It's not clear to me whether NFC should be applied - or what would be
> the consequences of applying NFC there (or not).


While I can't answer this question, it may be worth mentioning RFC 3987 which might not be directly applicable but also deals with the representation of non-ASCII data in URIs.

In section 3 it explicitly asks for NFC-normalization _before_ applying percent-encoding. I can't tell what's the rationale behind this decision but possibly the behaviour of URI.toASCIIString() is in the spirit of these rules.

From github.com+1204330+overheadhunter at openjdk.java.net  Wed Jan 13 19:01:19 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 13 Jan 2021 19:01:19 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+ [v3]
In-Reply-To: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
Message-ID: <hSGbrqPKmkCiB_ZhZFWzNZmd4j2FGndSgVXsxkFFLcE=.d785cbad-7522-4e63-aed4-770a6906d4ba@github.com>

> This adds support for UserDefinedFileAttributeView on macOS 10.4 and newer.
> 
> While the main audience for this will probably be macOS users, the relevant changes take place in (mostly existing) classes carrying BSD in their names as none of this is really macOS-specific.
> 
> Code is mostly copied from the Linux implementation except for three differences:
> 1. max length for attribute names is 127 bytes
> 2. we know for sure that APFS and HFS+ support extended attributes, therefore we [simply return `true`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L114-L118) from `supportsFileAttributeView(UserDefinedFileAttributeView.class)` for these two FS types, while for all other types support is determined experimentally in [`isExtendedAttributesEnabled(...)`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L83-L100)
> 3. For the aforementioned check the new `UnixConstants.ENOATTR` is added, which [seems to be macOS and BSD-specific](https://mail-index.netbsd.org/tech-kern/2012/04/30/msg013090.html).
> 
> As discussed in the mailing list, for ease of tracking changes it is not a goal of this patch to modernize the existing Linux implementation, nor to deduplicate anything.

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

  removed comments
  that don't provide any insights not available on the native methods' man pages

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2017/files
  - new: https://git.openjdk.java.net/jdk/pull/2017/files/5d00aa62..bcd206c2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2017&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2017&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/2017

From daniel.fuchs at oracle.com  Wed Jan 13 19:11:16 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Jan 2021 19:11:16 +0000
Subject: Difference in encoding semantics of URI returned by File.toURI
 and Path.toUri representing the same file
In-Reply-To: <9B159D6D-8AF4-414C-A86A-ACFD34D67288@gmail.com>
References: <3cd8d31d-1640-a855-4ba2-bf05be8adfe0@gmail.com>
 <08edf854-6414-800f-4fa4-2f06d234e6a6@oracle.com>
 <9B159D6D-8AF4-414C-A86A-ACFD34D67288@gmail.com>
Message-ID: <970649d3-c121-d965-30c1-f09d8755c572@oracle.com>

Hi Sebastian,

On 13/01/2021 18:45, Sebastian Stenzel wrote:
>> [...]
>> It's not clear to me whether NFC should be applied - or what would be
>> the consequences of applying NFC there (or not).
> 
> While I can't answer this question, it may be worth mentioning RFC 3987 which might not be directly applicable but also deals with the representation of non-ASCII data in URIs.
> 
> In section 3 it explicitly asks for NFC-normalization_before_  applying percent-encoding. I can't tell what's the rationale behind this decision but possibly the behaviour of URI.toASCIIString() is in the spirit of these rules.

Yes - I believe URI does the right thing.

I was however musing about changing the behavior of Path.toURI() in
that respect, and whether using NFC or not in Path.toURI() could
potentially prevent Path.of(URI) to find back the same file on the
file system.

best regards,

-- daniel

From bpb at openjdk.java.net  Thu Jan 14 16:50:18 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 14 Jan 2021 16:50:18 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe
Message-ID: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>

Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. No test is included as the code is covered well by existing tests.

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

Commit messages:
 - 8253478: (se) epoll Selector should use eventfd for wakeup instead of pipe

Changes: https://git.openjdk.java.net/jdk/pull/2082/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253478
  Stats: 155 lines in 3 files changed: 142 ins; 4 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2082.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2082/head:pull/2082

PR: https://git.openjdk.java.net/jdk/pull/2082

From alanb at openjdk.java.net  Thu Jan 14 17:03:10 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 14 Jan 2021 17:03:10 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe
In-Reply-To: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
Message-ID: <l1XpPLhhm48_iBAmYhCo4XFp3lWQh9K-9CpvKVA_yL4=.cf1ee731-e826-4ebd-85dc-4238b357d901@github.com>

On Thu, 14 Jan 2021 16:44:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.

@bplb I think it's too premature to ask us to review this until you have some performance data. Do we have any existing micros for wakeup?

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Thu Jan 14 17:07:04 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 14 Jan 2021 17:07:04 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe
In-Reply-To: <l1XpPLhhm48_iBAmYhCo4XFp3lWQh9K-9CpvKVA_yL4=.cf1ee731-e826-4ebd-85dc-4238b357d901@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <l1XpPLhhm48_iBAmYhCo4XFp3lWQh9K-9CpvKVA_yL4=.cf1ee731-e826-4ebd-85dc-4238b357d901@github.com>
Message-ID: <Mnm2ewxWHOv3Bbp1RvKrd_qdrjRx4y2D5s_v8_TfstE=.6437c1f1-4281-46ef-adcd-7b0972e117d6@github.com>

On Thu, 14 Jan 2021 17:00:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.
>
> @bplb I think it's too premature to ask us to review this until you have some performance data. Do we have any existing micros for wakeup?

Yes. I have one based on the Wakeup test but it is rather ugly.

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Thu Jan 14 20:47:01 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 14 Jan 2021 20:47:01 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe
In-Reply-To: <Mnm2ewxWHOv3Bbp1RvKrd_qdrjRx4y2D5s_v8_TfstE=.6437c1f1-4281-46ef-adcd-7b0972e117d6@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <l1XpPLhhm48_iBAmYhCo4XFp3lWQh9K-9CpvKVA_yL4=.cf1ee731-e826-4ebd-85dc-4238b357d901@github.com>
 <Mnm2ewxWHOv3Bbp1RvKrd_qdrjRx4y2D5s_v8_TfstE=.6437c1f1-4281-46ef-adcd-7b0972e117d6@github.com>
Message-ID: <NM4-rB4SqUwAsAkYDQxDgTFLuaf1PPbxF7fohIukT5c=.437e5cd9-cca2-4737-87bb-51b950eac5be@github.com>

On Thu, 14 Jan 2021 17:03:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> @bplb I think it's too premature to ask us to review this until you have some performance data. Do we have any existing micros for wakeup?
>
> Yes. I have one based on the Wakeup test but it is rather ugly.

This simple benchmark below gives results for the `epoll(7)`-based `Selector` which are three to four percent faster for the version which uses `eventfd(2)` for wakeup.

@State(Scope.Thread)
public class EventFDBench {
    private Selector sel;

    @Setup(Level.Iteration)
    public void setup() throws IOException {
        sel = Selector.open();
    }

    @Benchmark
    public int test() throws IOException {
        return sel.wakeup().select();
    }
}

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Thu Jan 14 22:53:24 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 14 Jan 2021 22:53:24 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v2]
In-Reply-To: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
Message-ID: <d9p895UebPbWYi10buqR9z_wyxYjxzYqS6Iqgw0S35Y=.0865ac1c-d463-4675-88d6-9aef22baf479@github.com>

> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.

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

  8253478: correct initialization of non-blocking flag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2082/files
  - new: https://git.openjdk.java.net/jdk/pull/2082/files/488c46cb..c1d5338e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From alanb at openjdk.java.net  Fri Jan 15 11:22:09 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Jan 2021 11:22:09 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+ [v3]
In-Reply-To: <hSGbrqPKmkCiB_ZhZFWzNZmd4j2FGndSgVXsxkFFLcE=.d785cbad-7522-4e63-aed4-770a6906d4ba@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
 <hSGbrqPKmkCiB_ZhZFWzNZmd4j2FGndSgVXsxkFFLcE=.d785cbad-7522-4e63-aed4-770a6906d4ba@github.com>
Message-ID: <RBHCn_I9Gr-JAGtqzytu6ONpxVL2IXwsdVN7ztwj49A=.abc9c649-ac3b-4974-acbb-cd349c6510b9@github.com>

On Wed, 13 Jan 2021 19:01:19 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

>> This adds support for UserDefinedFileAttributeView on macOS 10.4 and newer.
>> 
>> While the main audience for this will probably be macOS users, the relevant changes take place in (mostly existing) classes carrying BSD in their names as none of this is really macOS-specific.
>> 
>> Code is mostly copied from the Linux implementation except for three differences:
>> 1. max length for attribute names is 127 bytes
>> 2. we know for sure that APFS and HFS+ support extended attributes, therefore we [simply return `true`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L114-L118) from `supportsFileAttributeView(UserDefinedFileAttributeView.class)` for these two FS types, while for all other types support is determined experimentally in [`isExtendedAttributesEnabled(...)`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L83-L100)
>> 3. For the aforementioned check the new `UnixConstants.ENOATTR` is added, which [seems to be macOS and BSD-specific](https://mail-index.netbsd.org/tech-kern/2012/04/30/msg013090.html).
>> 
>> As discussed in the mailing list, for ease of tracking changes it is not a goal of this patch to modernize the existing Linux implementation, nor to deduplicate anything.
>
> Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed comments
>   that don't provide any insights not available on the native methods' man pages

src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java line 72:

> 70:      */
> 71:     static int fgetxattr(int fd, byte[] name, long valueAddress, int valueLen) throws UnixException
> 72:     {

Do you remind reformatting the changes to BsdNativeDispatcher.java to keep it consistent with the existing code and UnixNativeDispatcher?  Otherwise I think the patch is good and I can sponsor when you are ready.

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

PR: https://git.openjdk.java.net/jdk/pull/2017

From alanb at openjdk.java.net  Fri Jan 15 11:31:05 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Jan 2021 11:31:05 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe
In-Reply-To: <NM4-rB4SqUwAsAkYDQxDgTFLuaf1PPbxF7fohIukT5c=.437e5cd9-cca2-4737-87bb-51b950eac5be@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <l1XpPLhhm48_iBAmYhCo4XFp3lWQh9K-9CpvKVA_yL4=.cf1ee731-e826-4ebd-85dc-4238b357d901@github.com>
 <Mnm2ewxWHOv3Bbp1RvKrd_qdrjRx4y2D5s_v8_TfstE=.6437c1f1-4281-46ef-adcd-7b0972e117d6@github.com>
 <NM4-rB4SqUwAsAkYDQxDgTFLuaf1PPbxF7fohIukT5c=.437e5cd9-cca2-4737-87bb-51b950eac5be@github.com>
Message-ID: <FQYcS9lMSTmDlmeAVXZPaXBRzX9HGhsFtwTOia-Fpss=.7ddb7d74-b76b-4c4e-822d-bf2b973f3f12@github.com>

On Thu, 14 Jan 2021 20:44:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Yes. I have one based on the Wakeup test but it is rather ugly.
>
> This simple benchmark below gives results for the `epoll(7)`-based `Selector` which are three to four percent faster for the version which uses `eventfd(2)` for wakeup.
> 
> @State(Scope.Thread)
> public class EventFDBench {
>     private Selector sel;
> 
>     @Setup(Level.Iteration)
>     public void setup() throws IOException {
>         sel = Selector.open();
>     }
> 
>     @Benchmark
>     public int test() throws IOException {
>         return sel.wakeup().select();
>     }
> }

I did experiments with eventfd(2) a few years ago but didn't see any difference at the time. I think it would be useful to include the PR the results from the JMH runs so that there is at least some record of the results.

As regards the patch, I would have expected the only native code is be the method that creates the eventfd instance. The set/reset methods can be implemented with IOUtil.write1/drain1. Also I think the EventFD constructor needs a flag so decide the blocking mode, alternative we ignore it and using the existing IOUtil.configureBlocking.

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From alanb at openjdk.java.net  Fri Jan 15 11:46:01 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Jan 2021 11:46:01 GMT
Subject: RFR: 8257212: (bf spec) Clarify byte order of the buffer returned
 by CharBuffer.subsequence(int, int) [v2]
In-Reply-To: <nyphQxiG1SdiIufG2EohSAwbu7gHfYxOyNr-08HoFtQ=.f793f7db-a16b-4ef8-8073-b98b7c67fa7b@github.com>
References: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
 <nyphQxiG1SdiIufG2EohSAwbu7gHfYxOyNr-08HoFtQ=.f793f7db-a16b-4ef8-8073-b98b7c67fa7b@github.com>
Message-ID: <wJ6vlFYjSD5ER2z0L8zFWfeZVXpWfyh92tATdJeEcyc=.f3518817-66cd-42bf-b79c-54e4fcd77322@github.com>

On Wed, 13 Jan 2021 10:08:14 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Specification for CharBuffer::subSequence was missing clarification on the byte order of the returned CharBuffer. The returned order will always be the same as that of the original buffer. For example, subSequence() called on a CharBuffer with Little-Endian Byte Order will return a CharBuffer of Little-Endian Order. The specification has been changed to reflect this.
>> 
>> In addition to this, some additional testing was added to improve test coverage of this behavior. Testing for the Byte Order of different types of Buffer is generated via the template Order-X.java.template which serves to verify the original Byte Order of a Buffer and subsequently verify that the same Byte Order is present after operations such as CharBuffer::subSequence
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8259638
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8257212: Updated copyright year

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2049

From github.com+1204330+overheadhunter at openjdk.java.net  Fri Jan 15 11:52:05 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Fri, 15 Jan 2021 11:52:05 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+ [v3]
In-Reply-To: <RBHCn_I9Gr-JAGtqzytu6ONpxVL2IXwsdVN7ztwj49A=.abc9c649-ac3b-4974-acbb-cd349c6510b9@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
 <hSGbrqPKmkCiB_ZhZFWzNZmd4j2FGndSgVXsxkFFLcE=.d785cbad-7522-4e63-aed4-770a6906d4ba@github.com>
 <RBHCn_I9Gr-JAGtqzytu6ONpxVL2IXwsdVN7ztwj49A=.abc9c649-ac3b-4974-acbb-cd349c6510b9@github.com>
Message-ID: <rH2q2kl1kw9hI1PjiyJwVV5wRZXRsG1QzLnFxfLWDj8=.7d8cfdbd-81f1-4818-b02b-88f655356926@github.com>

On Fri, 15 Jan 2021 11:19:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed comments
>>   that don't provide any insights not available on the native methods' man pages
>
> src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java line 72:
> 
>> 70:      */
>> 71:     static int fgetxattr(int fd, byte[] name, long valueAddress, int valueLen) throws UnixException
>> 72:     {
> 
> Do you remind reformatting the changes to BsdNativeDispatcher.java to keep it consistent with the existing code and UnixNativeDispatcher?  Otherwise I think the patch is good and I can sponsor when you are ready.

Tbh, I didn't find any official style guide (just for JavaFX). Should I hard wrap at 80 chars or what is the requirement here?

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

PR: https://git.openjdk.java.net/jdk/pull/2017

From github.com+1204330+overheadhunter at openjdk.java.net  Fri Jan 15 12:36:24 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Fri, 15 Jan 2021 12:36:24 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+ [v4]
In-Reply-To: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
Message-ID: <ImwUcMyC4-NGAP3GquJHF8gZkQuwE8nIykm7C38AlSc=.c797685f-6e90-43a8-a224-9fce04bfd0b3@github.com>

> This adds support for UserDefinedFileAttributeView on macOS 10.4 and newer.
> 
> While the main audience for this will probably be macOS users, the relevant changes take place in (mostly existing) classes carrying BSD in their names as none of this is really macOS-specific.
> 
> Code is mostly copied from the Linux implementation except for three differences:
> 1. max length for attribute names is 127 bytes
> 2. we know for sure that APFS and HFS+ support extended attributes, therefore we [simply return `true`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L114-L118) from `supportsFileAttributeView(UserDefinedFileAttributeView.class)` for these two FS types, while for all other types support is determined experimentally in [`isExtendedAttributesEnabled(...)`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L83-L100)
> 3. For the aforementioned check the new `UnixConstants.ENOATTR` is added, which [seems to be macOS and BSD-specific](https://mail-index.netbsd.org/tech-kern/2012/04/30/msg013090.html).
> 
> As discussed in the mailing list, for ease of tracking changes it is not a goal of this patch to modernize the existing Linux implementation, nor to deduplicate anything.

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

  wrap code lines at 90 chars and comments at 92 chars
  (matching format in LinuxNativeDispatcher.java)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2017/files
  - new: https://git.openjdk.java.net/jdk/pull/2017/files/bcd206c2..9258c370

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2017&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2017&range=02-03

  Stats: 16 lines in 1 file changed: 6 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2017/head:pull/2017

PR: https://git.openjdk.java.net/jdk/pull/2017

From alanb at openjdk.java.net  Fri Jan 15 13:03:02 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Jan 2021 13:03:02 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+ [v3]
In-Reply-To: <rH2q2kl1kw9hI1PjiyJwVV5wRZXRsG1QzLnFxfLWDj8=.7d8cfdbd-81f1-4818-b02b-88f655356926@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
 <hSGbrqPKmkCiB_ZhZFWzNZmd4j2FGndSgVXsxkFFLcE=.d785cbad-7522-4e63-aed4-770a6906d4ba@github.com>
 <RBHCn_I9Gr-JAGtqzytu6ONpxVL2IXwsdVN7ztwj49A=.abc9c649-ac3b-4974-acbb-cd349c6510b9@github.com>
 <rH2q2kl1kw9hI1PjiyJwVV5wRZXRsG1QzLnFxfLWDj8=.7d8cfdbd-81f1-4818-b02b-88f655356926@github.com>
Message-ID: <O8GspewWJKgrVtFOPpsCUcIdDx9hTbU_iW9hLUdJpNU=.a01b3840-95aa-41fb-82e4-a34a7a754503@github.com>

On Fri, 15 Jan 2021 11:49:34 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

>> src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java line 72:
>> 
>>> 70:      */
>>> 71:     static int fgetxattr(int fd, byte[] name, long valueAddress, int valueLen) throws UnixException
>>> 72:     {
>> 
>> Do you remind reformatting the changes to BsdNativeDispatcher.java to keep it consistent with the existing code and UnixNativeDispatcher?  Otherwise I think the patch is good and I can sponsor when you are ready.
>
> Tbh, I didn't find any official style guide (just for JavaFX). Should I hard wrap at 80 chars or what is the requirement here?

Sorry, there isn't an agreed JDK wide style code. When it doubt, best to keep the style consistent with the existing code in the area. The main issue with BsdNativeDispatcher is that the line breaks are in unusual places.

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

PR: https://git.openjdk.java.net/jdk/pull/2017

From github.com+1204330+overheadhunter at openjdk.java.net  Fri Jan 15 13:21:02 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Fri, 15 Jan 2021 13:21:02 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+ [v3]
In-Reply-To: <O8GspewWJKgrVtFOPpsCUcIdDx9hTbU_iW9hLUdJpNU=.a01b3840-95aa-41fb-82e4-a34a7a754503@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
 <hSGbrqPKmkCiB_ZhZFWzNZmd4j2FGndSgVXsxkFFLcE=.d785cbad-7522-4e63-aed4-770a6906d4ba@github.com>
 <RBHCn_I9Gr-JAGtqzytu6ONpxVL2IXwsdVN7ztwj49A=.abc9c649-ac3b-4974-acbb-cd349c6510b9@github.com>
 <rH2q2kl1kw9hI1PjiyJwVV5wRZXRsG1QzLnFxfLWDj8=.7d8cfdbd-81f1-4818-b02b-88f655356926@github.com>
 <O8GspewWJKgrVtFOPpsCUcIdDx9hTbU_iW9hLUdJpNU=.a01b3840-95aa-41fb-82e4-a34a7a754503@github.com>
Message-ID: <1A4V0aEM7IuLDqQ1BQ88mqNWUS-NLpni8i4B2Ph0e4k=.553eaa9b-4ff0-434a-b737-0a1dfc49e281@github.com>

On Fri, 15 Jan 2021 13:00:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tbh, I didn't find any official style guide (just for JavaFX). Should I hard wrap at 80 chars or what is the requirement here?
>
> Sorry, there isn't an agreed JDK wide style code. When it doubt, best to keep the style consistent with the existing code in the area. The main issue with BsdNativeDispatcher is that the line breaks are in unusual places.

Oh if you're referring to the opening bracket being on a new line, that is already inconsistent in the Linux implementation, as well. If one tries to find a rule for this, it could be that the bracket should be on a new line, if the signature does't fit into a single line.
In my latest commit I think I conformed to this style.

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

PR: https://git.openjdk.java.net/jdk/pull/2017

From ccleary at openjdk.java.net  Fri Jan 15 14:10:03 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 15 Jan 2021 14:10:03 GMT
Subject: Integrated: 8257212: (bf spec) Clarify byte order of the buffer
 returned by CharBuffer.subsequence(int, int)
In-Reply-To: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
References: <xbiskAqut_f8l0i9jhHVYiVDd0CWmoyrrEDOnOIEyJI=.93afcc6b-c286-42fa-9abe-b4327698c679@github.com>
Message-ID: <VZJTljE1sNv2XLGTWDjptBi4vWAEYjjSEXlS5LpYW68=.7bb11924-5866-41d3-bc7a-3d2009325ee0@github.com>

On Tue, 12 Jan 2021 13:47:54 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> Specification for CharBuffer::subSequence was missing clarification on the byte order of the returned CharBuffer. The returned order will always be the same as that of the original buffer. For example, subSequence() called on a CharBuffer with Little-Endian Byte Order will return a CharBuffer of Little-Endian Order. The specification has been changed to reflect this.
> 
> In addition to this, some additional testing was added to improve test coverage of this behavior. Testing for the Byte Order of different types of Buffer is generated via the template Order-X.java.template which serves to verify the original Byte Order of a Buffer and subsequently verify that the same Byte Order is present after operations such as CharBuffer::subSequence
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8259638

This pull request has now been integrated.

Changeset: 707bce08
Author:    Conor Cleary <ccleary at openjdk.org>
Committer: Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/707bce08
Stats:     194 lines in 8 files changed: 183 ins; 0 del; 11 mod

8257212: (bf spec) Clarify byte order of the buffer returned by CharBuffer.subsequence(int,int)

Reviewed-by: chegar, bpb, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/2049

From brian.burkhalter at oracle.com  Fri Jan 15 16:35:15 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 15 Jan 2021 08:35:15 -0800
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe
In-Reply-To: <FQYcS9lMSTmDlmeAVXZPaXBRzX9HGhsFtwTOia-Fpss=.7ddb7d74-b76b-4c4e-822d-bf2b973f3f12@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <l1XpPLhhm48_iBAmYhCo4XFp3lWQh9K-9CpvKVA_yL4=.cf1ee731-e826-4ebd-85dc-4238b357d901@github.com>
 <Mnm2ewxWHOv3Bbp1RvKrd_qdrjRx4y2D5s_v8_TfstE=.6437c1f1-4281-46ef-adcd-7b0972e117d6@github.com>
 <NM4-rB4SqUwAsAkYDQxDgTFLuaf1PPbxF7fohIukT5c=.437e5cd9-cca2-4737-87bb-51b950eac5be@github.com>
 <FQYcS9lMSTmDlmeAVXZPaXBRzX9HGhsFtwTOia-Fpss=.7ddb7d74-b76b-4c4e-822d-bf2b973f3f12@github.com>
Message-ID: <A3E23EBF-B278-4712-8940-4291197B97DE@oracle.com>


> On Jan 15, 2021, at 3:31 AM, Alan Bateman <alanb at openjdk.java.net> wrote:
> 
> I did experiments with eventfd(2) a few years ago but didn't see any difference at the time. I think it would be useful to include the PR the results from the JMH runs so that there is at least some record of the results.

I?ll do that.

> As regards the patch, I would have expected the only native code is be the method that creates the eventfd instance. The set/reset methods can be implemented with IOUtil.write1/drain1.

Reading or writing fewer than 8 bytes from / to the eventfd object will result in an EINVAL error. Yes, IOUtil.drain(int) could be used instead of EventFD.reset(), although its more complex, but there is no write() in IOUtil which does not require a FileDescriptor and a ByteBuffer, which seems like overkill here. A method IOUtil.write(int fd, long value) could be added however.

> Also I think the EventFD constructor needs a flag so decide the blocking mode, alternative we ignore it and using the existing IOUtil.configureBlocking.

Or maybe better yet just go with hard-coded blocking or non-blocking and dispense with the parameter.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210115/250820a9/attachment-0001.htm>

From alanb at openjdk.java.net  Fri Jan 15 19:09:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Jan 2021 19:09:03 GMT
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+ [v4]
In-Reply-To: <ImwUcMyC4-NGAP3GquJHF8gZkQuwE8nIykm7C38AlSc=.c797685f-6e90-43a8-a224-9fce04bfd0b3@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
 <ImwUcMyC4-NGAP3GquJHF8gZkQuwE8nIykm7C38AlSc=.c797685f-6e90-43a8-a224-9fce04bfd0b3@github.com>
Message-ID: <vFDoTEZL80Fh8KbUPMej0I2QonUiBODnnfk_1rbvQEE=.6877e8aa-7d85-4557-99d8-27483ce2a846@github.com>

On Fri, 15 Jan 2021 12:36:24 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

>> This adds support for UserDefinedFileAttributeView on macOS 10.4 and newer.
>> 
>> While the main audience for this will probably be macOS users, the relevant changes take place in (mostly existing) classes carrying BSD in their names as none of this is really macOS-specific.
>> 
>> Code is mostly copied from the Linux implementation except for three differences:
>> 1. max length for attribute names is 127 bytes
>> 2. we know for sure that APFS and HFS+ support extended attributes, therefore we [simply return `true`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L114-L118) from `supportsFileAttributeView(UserDefinedFileAttributeView.class)` for these two FS types, while for all other types support is determined experimentally in [`isExtendedAttributesEnabled(...)`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L83-L100)
>> 3. For the aforementioned check the new `UnixConstants.ENOATTR` is added, which [seems to be macOS and BSD-specific](https://mail-index.netbsd.org/tech-kern/2012/04/30/msg013090.html).
>> 
>> As discussed in the mailing list, for ease of tracking changes it is not a goal of this patch to modernize the existing Linux implementation, nor to deduplicate anything.
>
> Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrap code lines at 90 chars and comments at 92 chars
>   (matching format in LinuxNativeDispatcher.java)

Thanks for the updates. I can sponsor once, you'll need to enter "/integrate"

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2017

From sebastian.stenzel at gmail.com  Fri Jan 15 20:19:21 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Fri, 15 Jan 2021 21:19:21 +0100
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+ [v4]
In-Reply-To: <vFDoTEZL80Fh8KbUPMej0I2QonUiBODnnfk_1rbvQEE=.6877e8aa-7d85-4557-99d8-27483ce2a846@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
 <ImwUcMyC4-NGAP3GquJHF8gZkQuwE8nIykm7C38AlSc=.c797685f-6e90-43a8-a224-9fce04bfd0b3@github.com>
 <vFDoTEZL80Fh8KbUPMej0I2QonUiBODnnfk_1rbvQEE=.6877e8aa-7d85-4557-99d8-27483ce2a846@github.com>
Message-ID: <68499BBD-799D-45E3-AFE1-EF55D56A0093@gmail.com>


> On 15. Jan 2021, at 20:09, Alan Bateman <alanb at openjdk.java.net> wrote:
> 
> Thanks for the updates. I can sponsor once, you'll need to enter "/integrate"
> 
> -------------
> 
> Marked as reviewed by alanb (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/2017

Thank you, Alan, for guiding me through the process and reviewing the changes!

Regarding the deduplication I already have some ideas and questions, but I think I'll do this in a new thread in a couple of days.

From bpb at openjdk.java.net  Fri Jan 15 23:11:25 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 15 Jan 2021 23:11:25 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v3]
In-Reply-To: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
Message-ID: <pvPcEnVbomhTA4vz0L6FtfCTt3heHypWMFsoTenxOHg=.fdce7419-bf49-447d-9cb0-2d88c5fe7571@github.com>

> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.

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

  8253478: Add IOUtil.write(int,long); implement set() and reset() in EventFD using IOUtil methods.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2082/files
  - new: https://git.openjdk.java.net/jdk/pull/2082/files/c1d5338e..8a95f23f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=01-02

  Stats: 55 lines in 4 files changed: 12 ins; 35 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2082.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2082/head:pull/2082

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Fri Jan 15 23:14:02 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 15 Jan 2021 23:14:02 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe
In-Reply-To: <pOYiGYq2J4OZehaYVyvZdATrqSsfv4s2tY7uyJ7n6H4=.9898136d-ec3b-4532-81de-568f2d91f8ed@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <l1XpPLhhm48_iBAmYhCo4XFp3lWQh9K-9CpvKVA_yL4=.cf1ee731-e826-4ebd-85dc-4238b357d901@github.com>
 <Mnm2ewxWHOv3Bbp1RvKrd_qdrjRx4y2D5s_v8_TfstE=.6437c1f1-4281-46ef-adcd-7b0972e117d6@github.com>
 <NM4-rB4SqUwAsAkYDQxDgTFLuaf1PPbxF7fohIukT5c=.437e5cd9-cca2-4737-87bb-51b950eac5be@github.com>
 <FQYcS9lMSTmDlmeAVXZPaXBRzX9HGhsFtwTOia-Fpss=.7ddb7d74-b76b-4c4e-822d-bf2b973f3f12@github.com>
 <pOYiGYq2J4OZehaYVyvZdATrqSsfv4s2tY7uyJ7n6H4=.9898136d-ec3b-4532-81de-568f2d91f8ed@github.com>
Message-ID: <BPo7q4N63XdWEeqFpcvgjV-g466JXojOQTYku1pn6Qw=.f6e04ad0-8076-40b1-9a99-54bd7214bd11@github.com>

On Fri, 15 Jan 2021 23:05:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I did experiments with eventfd(2) a few years ago but didn't see any difference at the time. I think it would be useful to include the PR the results from the JMH runs so that there is at least some record of the results.
>> 
>> As regards the patch, I would have expected the only native code is be the method that creates the eventfd instance. The set/reset methods can be implemented with IOUtil.write1/drain1. Also I think the EventFD constructor needs a flag so decide the blocking mode, alternative we ignore it and using the existing IOUtil.configureBlocking.
>
> Benchmark output for commit 3:
> 
> 1 fork, 5 10s warmup iterations, 10 10s measurement iterations, 1 thread
> pipe wakeup
> 
> Result "org.sample.EventFDBench.test":
>   674120.350 ?(99.9%) 2246.122 ops/s [Average]
>   (min, avg, max) = (671278.574, 674120.350, 676866.600), stdev = 1485.671
>   CI (99.9%): [671874.229, 676366.472] (assumes normal distribution)
> 
> Result "org.sample.EventFDBench.test":
>   676831.218 ?(99.9%) 2353.488 ops/s [Average]
>   (min, avg, max) = (673745.955, 676831.218, 678758.514), stdev = 1556.686
>   CI (99.9%): [674477.731, 679184.706] (assumes normal distribution)
> 
> Result "org.sample.EventFDBench.test":
>   675830.928 ?(99.9%) 3052.319 ops/s [Average]
>   (min, avg, max) = (671286.540, 675830.928, 679293.739), stdev = 2018.920
>   CI (99.9%): [672778.609, 678883.246] (assumes normal distribution)
> 
> eventfd wakeup
> 
> Result "org.sample.EventFDBench.test":
>   698126.388 ?(99.9%) 2776.885 ops/s [Average]
>   (min, avg, max) = (694253.565, 698126.388, 700086.784), stdev = 1836.738
>   CI (99.9%): [695349.503, 700903.273] (assumes normal distribution)
> 
> Result "org.sample.EventFDBench.test":
>   699992.095 ?(99.9%) 3653.650 ops/s [Average]
>   (min, avg, max) = (695504.040, 699992.095, 702932.998), stdev = 2416.663
>   CI (99.9%): [696338.445, 703645.746] (assumes normal distribution)
> 
> Result "org.sample.EventFDBench.test":
>   702140.433 ?(99.9%) 3019.100 ops/s [Average]
>   (min, avg, max) = (698291.810, 702140.433, 704818.744), stdev = 1996.948
>   CI (99.9%): [699121.333, 705159.533] (assumes normal distribution)
> 
> 
> 1 fork, 5 10s warmup iterations, 10 10s measurement iterations, 6 threads
> pipe wakeup
> 
> Result "org.sample.EventFDBench.test":
>   3223142.871 ?(99.9%) 94755.560 ops/s [Average]
>   (min, avg, max) = (3120710.890, 3223142.871, 3283407.281), stdev = 62674.936
>   CI (99.9%): [3128387.312, 3317898.431] (assumes normal distribution)
> 
> Result "org.sample.EventFDBench.test":
>   3260747.260 ?(99.9%) 11514.840 ops/s [Average]
>   (min, avg, max) = (3248875.268, 3260747.260, 3268729.421), stdev = 7616.354
>   CI (99.9%): [3249232.419, 3272262.100] (assumes normal distribution)
> 
> Result "org.sample.EventFDBench.test":
>   3243306.245 ?(99.9%) 56893.385 ops/s [Average]
>   (min, avg, max) = (3160345.608, 3243306.245, 3277487.093), stdev = 37631.452
>   CI (99.9%): [3186412.859, 3300199.630] (assumes normal distribution)
> 
> eventfd wakeup
> 
> Result "org.sample.EventFDBench.test":
>   3340323.956 ?(99.9%) 38169.834 ops/s [Average]
>   (min, avg, max) = (3280464.427, 3340323.956, 3355415.702), stdev = 25246.982
>   CI (99.9%): [3302154.122, 3378493.790] (assumes normal distribution)
> 
> Result "org.sample.EventFDBench.test":
>   3344287.954 ?(99.9%) 46249.831 ops/s [Average]
>   (min, avg, max) = (3261670.180, 3344287.954, 3363007.332), stdev = 30591.400
>   CI (99.9%): [3298038.123, 3390537.786] (assumes normal distribution)
> 
> Result "org.sample.EventFDBench.test":
>   3353728.294 ?(99.9%) 40760.876 ops/s [Average]
>   (min, avg, max) = (3285776.202, 3353728.294, 3372002.914), stdev = 26960.796
>   CI (99.9%): [3312967.418, 3394489.170] (assumes normal distribution)

Throughput improvement as measured by the benchmark looks to be a bit over 3% for eventfd wakeup with respect to pipe wakeup. The maximum upper bound of the pipe wakeup confidence intervals is smaller than the minimum lower bound of the eventfd wakeup confidence intervals which suggests some degree of reliability.

Summary of benchmark results:
1 fork, 5 10s warmup iterations, 10 10s measurement iterations, 1 thread
pipe wakeup

Mean average: 675594.1653333333
Max CI upper bound: 679184.706

eventfd wakeup

Mean average: 700086.3053333334
Min CI lower bound: 695349.503
Throughput change: +3.6%

1 fork, 5 10s warmup iterations, 10 10s measurement iterations, 6 threads
pipe wakeup

Mean average: 3242398.7919999994
Max CI upper bound: 3317898.431

eventfd wakeup

Mean average: 3346113.4013333335
Min CI lower bound: 3298038.123
Throughput change: +3.2%

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Fri Jan 15 23:11:25 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 15 Jan 2021 23:11:25 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe
In-Reply-To: <FQYcS9lMSTmDlmeAVXZPaXBRzX9HGhsFtwTOia-Fpss=.7ddb7d74-b76b-4c4e-822d-bf2b973f3f12@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <l1XpPLhhm48_iBAmYhCo4XFp3lWQh9K-9CpvKVA_yL4=.cf1ee731-e826-4ebd-85dc-4238b357d901@github.com>
 <Mnm2ewxWHOv3Bbp1RvKrd_qdrjRx4y2D5s_v8_TfstE=.6437c1f1-4281-46ef-adcd-7b0972e117d6@github.com>
 <NM4-rB4SqUwAsAkYDQxDgTFLuaf1PPbxF7fohIukT5c=.437e5cd9-cca2-4737-87bb-51b950eac5be@github.com>
 <FQYcS9lMSTmDlmeAVXZPaXBRzX9HGhsFtwTOia-Fpss=.7ddb7d74-b76b-4c4e-822d-bf2b973f3f12@github.com>
Message-ID: <pOYiGYq2J4OZehaYVyvZdATrqSsfv4s2tY7uyJ7n6H4=.9898136d-ec3b-4532-81de-568f2d91f8ed@github.com>

On Fri, 15 Jan 2021 11:28:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This simple benchmark below gives results for the `epoll(7)`-based `Selector` which are three to four percent faster for the version which uses `eventfd(2)` for wakeup.
>> 
>> @State(Scope.Thread)
>> public class EventFDBench {
>>     private Selector sel;
>> 
>>     @Setup(Level.Iteration)
>>     public void setup() throws IOException {
>>         sel = Selector.open();
>>     }
>> 
>>     @Benchmark
>>     public int test() throws IOException {
>>         return sel.wakeup().select();
>>     }
>> }
>
> I did experiments with eventfd(2) a few years ago but didn't see any difference at the time. I think it would be useful to include the PR the results from the JMH runs so that there is at least some record of the results.
> 
> As regards the patch, I would have expected the only native code is be the method that creates the eventfd instance. The set/reset methods can be implemented with IOUtil.write1/drain1. Also I think the EventFD constructor needs a flag so decide the blocking mode, alternative we ignore it and using the existing IOUtil.configureBlocking.

Benchmark output for commit 3:

 fork, 5 10s warmup iterations, 10 10s measurement iterations, 1 thread
pipe wakeup

Result "org.sample.EventFDBench.test":
  674120.350 ?(99.9%) 2246.122 ops/s [Average]
  (min, avg, max) = (671278.574, 674120.350, 676866.600), stdev = 1485.671
  CI (99.9%): [671874.229, 676366.472] (assumes normal distribution)

Result "org.sample.EventFDBench.test":
  676831.218 ?(99.9%) 2353.488 ops/s [Average]
  (min, avg, max) = (673745.955, 676831.218, 678758.514), stdev = 1556.686
  CI (99.9%): [674477.731, 679184.706] (assumes normal distribution)

Result "org.sample.EventFDBench.test":
  675830.928 ?(99.9%) 3052.319 ops/s [Average]
  (min, avg, max) = (671286.540, 675830.928, 679293.739), stdev = 2018.920
  CI (99.9%): [672778.609, 678883.246] (assumes normal distribution)

eventfd wakeup

Result "org.sample.EventFDBench.test":
  698126.388 ?(99.9%) 2776.885 ops/s [Average]
  (min, avg, max) = (694253.565, 698126.388, 700086.784), stdev = 1836.738
  CI (99.9%): [695349.503, 700903.273] (assumes normal distribution)

Result "org.sample.EventFDBench.test":
  699992.095 ?(99.9%) 3653.650 ops/s [Average]
  (min, avg, max) = (695504.040, 699992.095, 702932.998), stdev = 2416.663
  CI (99.9%): [696338.445, 703645.746] (assumes normal distribution)

Result "org.sample.EventFDBench.test":
  702140.433 ?(99.9%) 3019.100 ops/s [Average]
  (min, avg, max) = (698291.810, 702140.433, 704818.744), stdev = 1996.948
  CI (99.9%): [699121.333, 705159.533] (assumes normal distribution)


1 fork, 5 10s warmup iterations, 10 10s measurement iterations, 6 threads
pipe wakeup

Result "org.sample.EventFDBench.test":
  3223142.871 ?(99.9%) 94755.560 ops/s [Average]
  (min, avg, max) = (3120710.890, 3223142.871, 3283407.281), stdev = 62674.936
  CI (99.9%): [3128387.312, 3317898.431] (assumes normal distribution)

Result "org.sample.EventFDBench.test":
  3260747.260 ?(99.9%) 11514.840 ops/s [Average]
  (min, avg, max) = (3248875.268, 3260747.260, 3268729.421), stdev = 7616.354
  CI (99.9%): [3249232.419, 3272262.100] (assumes normal distribution)

Result "org.sample.EventFDBench.test":
  3243306.245 ?(99.9%) 56893.385 ops/s [Average]
  (min, avg, max) = (3160345.608, 3243306.245, 3277487.093), stdev = 37631.452
  CI (99.9%): [3186412.859, 3300199.630] (assumes normal distribution)

eventfd wakeup

Result "org.sample.EventFDBench.test":
  3340323.956 ?(99.9%) 38169.834 ops/s [Average]
  (min, avg, max) = (3280464.427, 3340323.956, 3355415.702), stdev = 25246.982
  CI (99.9%): [3302154.122, 3378493.790] (assumes normal distribution)

Result "org.sample.EventFDBench.test":
  3344287.954 ?(99.9%) 46249.831 ops/s [Average]
  (min, avg, max) = (3261670.180, 3344287.954, 3363007.332), stdev = 30591.400
  CI (99.9%): [3298038.123, 3390537.786] (assumes normal distribution)

Result "org.sample.EventFDBench.test":
  3353728.294 ?(99.9%) 40760.876 ops/s [Average]
  (min, avg, max) = (3285776.202, 3353728.294, 3372002.914), stdev = 26960.796
  CI (99.9%): [3312967.418, 3394489.170] (assumes normal distribution)

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From github.com+1204330+overheadhunter at openjdk.java.net  Sat Jan 16 08:39:15 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Sat, 16 Jan 2021 08:39:15 GMT
Subject: Integrated: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+
In-Reply-To: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
Message-ID: <hImrxI4DzelMQHvE5Un62nn5PYU53_dehd0plrCHgMo=.6735eb78-daa8-4997-afb1-60237adcf6b5@github.com>

On Sun, 10 Jan 2021 17:17:16 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

> This adds support for UserDefinedFileAttributeView on macOS 10.4 and newer.
> 
> While the main audience for this will probably be macOS users, the relevant changes take place in (mostly existing) classes carrying BSD in their names as none of this is really macOS-specific.
> 
> Code is mostly copied from the Linux implementation except for three differences:
> 1. max length for attribute names is 127 bytes
> 2. we know for sure that APFS and HFS+ support extended attributes, therefore we [simply return `true`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L114-L118) from `supportsFileAttributeView(UserDefinedFileAttributeView.class)` for these two FS types, while for all other types support is determined experimentally in [`isExtendedAttributesEnabled(...)`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L83-L100)
> 3. For the aforementioned check the new `UnixConstants.ENOATTR` is added, which [seems to be macOS and BSD-specific](https://mail-index.netbsd.org/tech-kern/2012/04/30/msg013090.html).
> 
> As discussed in the mailing list, for ease of tracking changes it is not a goal of this patch to modernize the existing Linux implementation, nor to deduplicate anything.

This pull request has now been integrated.

Changeset: afd3f78a
Author:    Sebastian Stenzel <sebastian.stenzel at skymatic.de>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/afd3f78a
Stats:     204 lines in 7 files changed: 198 ins; 0 del; 6 mod

8030048: (fs) Support UserDefinedFileAttributeView/extended attributes on OS X / HFS+

Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk/pull/2017

From Alan.Bateman at oracle.com  Sat Jan 16 16:01:58 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 16 Jan 2021 16:01:58 +0000
Subject: RFR: JDK-8030048: (fs) Support
 UserDefinedFileAttributeView/extended attributes on OS X / HFS+ [v4]
In-Reply-To: <68499BBD-799D-45E3-AFE1-EF55D56A0093@gmail.com>
References: <Xp4rF9-IpRiZGICYjGoPwECb458cseEBvsQHJmXH1zo=.e7c09c09-a87c-40a1-a251-6a38018f1267@github.com>
 <ImwUcMyC4-NGAP3GquJHF8gZkQuwE8nIykm7C38AlSc=.c797685f-6e90-43a8-a224-9fce04bfd0b3@github.com>
 <vFDoTEZL80Fh8KbUPMej0I2QonUiBODnnfk_1rbvQEE=.6877e8aa-7d85-4557-99d8-27483ce2a846@github.com>
 <68499BBD-799D-45E3-AFE1-EF55D56A0093@gmail.com>
Message-ID: <fac7f851-04fb-cfc4-7886-e6faaeff1778@oracle.com>

On 15/01/2021 20:19, Sebastian Stenzel wrote:
> :
> Thank you, Alan, for guiding me through the process and reviewing the changes!
>
> Regarding the deduplication I already have some ideas and questions, but I think I'll do this in a new thread in a couple of days.
No problem, it's a good contribution for something that the maintainers 
in this area never got time to work on.

One issue is that has come up since the commit is that 
UserDefinedFileAttributeView/Basic.java is failing on macOS 10.13 
systems. I've created JDK-8259865 [1] to track it. I can't duplicate it 
on 10.14 and 10.15. I think the issue is that fgetxattr is not failing 
with -1/ERANGE when the buffer is too small. We may have to disable 
support for user defined file attributes on systems older than 10.14.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8259865

From alanb at openjdk.java.net  Sun Jan 17 08:32:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 17 Jan 2021 08:32:41 GMT
Subject: RFR: 8259865: (fs)
 test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java
 failing on macOS 10.13
Message-ID: <2DQTUrXdvVkWv7Be5rKgePRxxbIhrHdljYqkxemWLJM=.e68ba0db-5b35-4879-9433-b241875004e6@github.com>

This is a workaround to a bug in fgetxattr(2) on macOS 10.13.6 with APFS where it doesn't return -1/ERANGE when the buffer is too small.  This bug leads to UserDefinedFileAttributeView/Basic.java failing on macOS 10.13 systems, the test is passing on 10.14 and 10.15. The change just means that FileStore.supportsFileAttributeView will return false when asked if it supports UserDefinedFileAttributeView.class.

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

Commit messages:
 - 8259865: (fs) test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java failing on macOS 10.13

Changes: https://git.openjdk.java.net/jdk/pull/2112/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2112&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259865
  Stats: 22 lines in 1 file changed: 18 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2112.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2112/head:pull/2112

PR: https://git.openjdk.java.net/jdk/pull/2112

From dcubed at openjdk.java.net  Sun Jan 17 15:09:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 17 Jan 2021 15:09:01 GMT
Subject: RFR: 8259865: (fs)
 test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java
 failing on macOS 10.13
In-Reply-To: <2DQTUrXdvVkWv7Be5rKgePRxxbIhrHdljYqkxemWLJM=.e68ba0db-5b35-4879-9433-b241875004e6@github.com>
References: <2DQTUrXdvVkWv7Be5rKgePRxxbIhrHdljYqkxemWLJM=.e68ba0db-5b35-4879-9433-b241875004e6@github.com>
Message-ID: <tjL32gcG3iQ-IuZjng79afW_NpgCcli-yR76NMpUFlM=.0ef85c16-9df2-4253-8ea1-822179a2ec76@github.com>

On Sun, 17 Jan 2021 08:24:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a workaround to a bug in fgetxattr(2) on macOS 10.13.6 with APFS where it doesn't return -1/ERANGE when the buffer is too small.  This bug leads to UserDefinedFileAttributeView/Basic.java failing on macOS 10.13 systems, the test is passing on 10.14 and 10.15. The change just means that FileStore.supportsFileAttributeView will return false when asked if it supports UserDefinedFileAttributeView.class.

Thumbs up!

Do you have any idea when fgetxattr() was fixed in 10.14? For example,
if it was fixed in 10.14.4, then it would be necessary to include a micro
version in the check. We may not care about that level of precision if
we presume that folks are running the version that we tested (10.14.6).

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2112

From sebastian.stenzel at gmail.com  Sun Jan 17 15:13:26 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Sun, 17 Jan 2021 16:13:26 +0100
Subject: RFR: 8259865: (fs)
 test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java
 failing on macOS 10.13
In-Reply-To: <tjL32gcG3iQ-IuZjng79afW_NpgCcli-yR76NMpUFlM=.0ef85c16-9df2-4253-8ea1-822179a2ec76@github.com>
References: <2DQTUrXdvVkWv7Be5rKgePRxxbIhrHdljYqkxemWLJM=.e68ba0db-5b35-4879-9433-b241875004e6@github.com>
 <tjL32gcG3iQ-IuZjng79afW_NpgCcli-yR76NMpUFlM=.0ef85c16-9df2-4253-8ea1-822179a2ec76@github.com>
Message-ID: <A863E432-B2BA-4E46-945C-E3368146A285@gmail.com>


> On 17. Jan 2021, at 16:09, Daniel D.Daugherty <dcubed at openjdk.java.net> wrote:
> 
> On Sun, 17 Jan 2021 08:24:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:
> 
>> This is a workaround to a bug in fgetxattr(2) on macOS 10.13.6 with APFS where it doesn't return -1/ERANGE when the buffer is too small.  This bug leads to UserDefinedFileAttributeView/Basic.java failing on macOS 10.13 systems, the test is passing on 10.14 and 10.15. The change just means that FileStore.supportsFileAttributeView will return false when asked if it supports UserDefinedFileAttributeView.class.
> 
> Thumbs up!
> 
> Do you have any idea when fgetxattr() was fixed in 10.14? For example,
> if it was fixed in 10.14.4, then it would be necessary to include a micro
> version in the check. We may not care about that level of precision if
> we presume that folks are running the version that we tested (10.14.6).
> 
> -------------
> 
> Marked as reviewed by dcubed (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/2112

Maybe someone with access to Radar (Apple's bug tracker) can answer this. This is the only public information I found so far: https://openradar.appspot.com/44533931 <https://openradar.appspot.com/44533931>, which marks this as a duplicate of ticket 39173408.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210117/bf69a208/attachment.htm>

From alanb at openjdk.java.net  Sun Jan 17 16:33:23 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 17 Jan 2021 16:33:23 GMT
Subject: RFR: 8259865: (fs)
 test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java
 failing on macOS 10.13
In-Reply-To: <tjL32gcG3iQ-IuZjng79afW_NpgCcli-yR76NMpUFlM=.0ef85c16-9df2-4253-8ea1-822179a2ec76@github.com>
References: <2DQTUrXdvVkWv7Be5rKgePRxxbIhrHdljYqkxemWLJM=.e68ba0db-5b35-4879-9433-b241875004e6@github.com>
 <tjL32gcG3iQ-IuZjng79afW_NpgCcli-yR76NMpUFlM=.0ef85c16-9df2-4253-8ea1-822179a2ec76@github.com>
Message-ID: <tV94mhmMce_C4PugAvC4PYYG2DUFH6OhQAotRGUWD2o=.16356f3c-2933-4ede-91b7-7c38bf2963b5@github.com>

On Sun, 17 Jan 2021 15:06:13 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Do you have any idea when fgetxattr() was fixed in 10.14? For example,
> if it was fixed in 10.14.4, then it would be necessary to include a micro
> version in the check. We may not care about that level of precision if
> we presume that folks are running the version that we tested (10.14.6).

The 10.14.* systems that I could find are all up to date with 10.14.6. You may be right that it was fixed in an update but I don't think we have any way to find out. It's a real shame that Apple don't have a public issue tracker. So let's go with the current fix for now. I assume 10.13 will be EOL soon, in which case we can stop the os.version check. Thanks for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/2112

From kustos at gmx.net  Sun Jan 17 17:48:04 2021
From: kustos at gmx.net (Philippe Marschall)
Date: Sun, 17 Jan 2021 18:48:04 +0100
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
 <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
Message-ID: <addf994f-ee6a-c9f7-535e-50f1dce454f7@gmx.net>



On 05.01.21 01:53, Brian Burkhalter wrote:
> On Thu, 31 Dec 2020 10:11:58 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:
> ...
>
> How does the performance of `InputStreamReader.read(CharBuffer)` compare for the case where only the change to `Reader` is made versus if all your proposed changes are applied?

I left the delegating one in InputStreamReader in but removed all
changes in StreamDecoder. Performance looks pretty good:

on-heap CharBuffer
- Throughput is a slightly lower than with the changes but close and
still better than before.
- Allocation rate is drastically reduced and comparable to the results
with the changes except for small buffer sizes (128 bytes).

off-heap CharBuffer
- Relative throughput depends on the buffer size. For small buffers (128
bytes) throughput is a bit lower than master but increases with buffer
size. For 1 KB buffers it is about even, for 1 MB buffers it is better.
Throughput is a lot better than with the StreamDecoder changes without
intermediate allocation, there we lose about one half to two thirds of
throughput.
- Allocation rate stays high (1.5 - 3 GB/s) and only drops with large
buffer sizes (1 MB) to 20 - 30 MB/s. The StreamDecoder changes cause the
allocation rate to drop to almost zero.

To be honest backing out of the StreamDecoder changes looks like a good
comprise to me to reduce the risk while still improving throughput and
reducing allocation rate, especially in the on-heap path.

Looking a bit further I wonder if CharArrayReader and StringReader
should implement #read(CharBuffer) as well and call CharBuffer#put
directly. And maybe even #transferTo(Writer).


Cheers
Philippe

From alanb at openjdk.java.net  Sun Jan 17 18:16:36 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 17 Jan 2021 18:16:36 GMT
Subject: Integrated: 8259865: (fs)
 test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java
 failing on macOS 10.13
In-Reply-To: <2DQTUrXdvVkWv7Be5rKgePRxxbIhrHdljYqkxemWLJM=.e68ba0db-5b35-4879-9433-b241875004e6@github.com>
References: <2DQTUrXdvVkWv7Be5rKgePRxxbIhrHdljYqkxemWLJM=.e68ba0db-5b35-4879-9433-b241875004e6@github.com>
Message-ID: <01mURIfGyh94K-UAaAtrMg945HCQOUmo5Elj0gkUuKs=.1ff362fd-4542-49c5-94d4-a627b7373a93@github.com>

On Sun, 17 Jan 2021 08:24:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a workaround to a bug in fgetxattr(2) on macOS 10.13.6 with APFS where it doesn't return -1/ERANGE when the buffer is too small.  This bug leads to UserDefinedFileAttributeView/Basic.java failing on macOS 10.13 systems, the test is passing on 10.14 and 10.15. The change just means that FileStore.supportsFileAttributeView will return false when asked if it supports UserDefinedFileAttributeView.class.

This pull request has now been integrated.

Changeset: 5f2e280c
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5f2e280c
Stats:     22 lines in 1 file changed: 18 ins; 0 del; 4 mod

8259865: (fs) test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java failing on macOS 10.13

Reviewed-by: dcubed

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

PR: https://git.openjdk.java.net/jdk/pull/2112

From ecki at zusammenkunft.net  Mon Jan 18 00:39:42 2021
From: ecki at zusammenkunft.net (Bernd)
Date: Mon, 18 Jan 2021 01:39:42 +0100
Subject: Java and the NTFS Path weakness
Message-ID: <CABOR3+zJ+P-G3=nDPAQpUqq_-Fy_mBy6zZD_qoebHKToOvThUA@mail.gmail.com>

Hello,

you might have seen the media coverage on a Microsoft Windows 10 and
Windows Server problem where a certain NTFS internal path causes the
Windows driver to claim corruption and mark the filesystem dirty. (Some
even reported actual corruption of their filesystems).

The java.nio Path seems to be resistance against that, as it detects an
illegal path itself:

|  Welcome to JShell -- Version 11.0.9.1
|  For an introduction type: /help intro

jshell> var bad = "C:\\:$i30:$bitmap";
bad ==> "C:\\:$i30:$bitmap"

jshell> new File(bad).toPath()
|  Exception java.nio.file.InvalidPathException: Illegal char <:> at index
3: C:\:$i30:$bitmap
|        at WindowsPathParser.normalize (WindowsPathParser.java:182)
|        at WindowsPathParser.parse (WindowsPathParser.java:153)
|        at WindowsPathParser.parse (WindowsPathParser.java:77)
|        at WindowsPath.parse (WindowsPath.java:92)
|        at WindowsFileSystem.getPath (WindowsFileSystem.java:229)
|        at File.toPath (File.java:2292)
|        at (#6:1)

jshell> Paths.get(bad)
|  Exception java.nio.file.InvalidPathException: Illegal char <:> at index
3: C:\:$i30:$bitmap
|        at WindowsPathParser.normalize (WindowsPathParser.java:182)
|        at WindowsPathParser.parse (WindowsPathParser.java:153)
|        at WindowsPathParser.parse (WindowsPathParser.java:77)
|        at WindowsPath.parse (WindowsPath.java:92)
|        at WindowsFileSystem.getPath (WindowsFileSystem.java:229)
|        at Path.of (Path.java:147)
|        at Paths.get (Paths.java:69)
|        at (#7:1)

jshell> Path.of(bad)
|  Exception java.nio.file.InvalidPathException: Illegal char <:> at index
3: C:\:$i30:$bitmap
|        at WindowsPathParser.normalize (WindowsPathParser.java:182)
|        at WindowsPathParser.parse (WindowsPathParser.java:153)
|        at WindowsPathParser.parse (WindowsPathParser.java:77)
|        at WindowsPath.parse (WindowsPath.java:92)
|        at WindowsFileSystem.getPath (WindowsFileSystem.java:229)
|        at Path.of (Path.java:147)
|        at (#8:1)

(not sure if there is a way to construct a path without that normalization).

Unfortunally, however, the java.io.File and its IO functions to not provide
this protection, when you call

jshell> new File(bad).exists()
$9 ==> false

(or some other methods accessing the file) you will see the crash message
in the event log.

I am not sure if Java should or could filter that (however since java.nio
already does it might be an option, not sure however if Microsoft would be
faster and fixing that problem). But I thought I mention this here in case
you have Java server applications which derive file names from untrusted
user input (including uncompressing ZIP files).

Gruss
Bernd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210118/6174bc61/attachment.htm>

From github.com+471021+marschall at openjdk.java.net  Mon Jan 18 07:09:55 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Mon, 18 Jan 2021 07:09:55 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <tEZQI1hwWbNe6n5aZmAJYWN2xpTqwntGtNNVTIsjQ5Q=.82cbeddb-8468-4b4f-a770-a25b9c5f5acf@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
 <tEZQI1hwWbNe6n5aZmAJYWN2xpTqwntGtNNVTIsjQ5Q=.82cbeddb-8468-4b4f-a770-a25b9c5f5acf@github.com>
Message-ID: <37Kl80k2O6NjyqhlmduaOoRL12IJAd-4b1oBRFgZSGc=.272f8b3a-77d8-4471-96bd-2acf17600298@github.com>

On Sun, 10 Jan 2021 01:59:18 GMT, Brett Okken <github.com+2996845+bokken at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add unit tests
>>   
>>   - add unit test for Reader#read(CharBuffer)
>>   - add unit test for InputStreamReader#reader(CharBuffer)
>>   - test with both on-heap and off-heap buffers
>
> src/java.base/share/classes/java/io/Reader.java line 198:
> 
>> 196:         } else {
>> 197:             int remaining = target.remaining();
>> 198:             char cbuf[] = new char[Math.min(remaining, TRANSFER_BUFFER_SIZE)];
> 
> Would there be value in making this a (lazily created) member variable? That would allow a single instance to be reused. It seems likely that, if one call is made with a direct CharBuffer, subsequent calls will also be made with direct instances (probably same instance?).

I am not sure. It would help to reduce the allocation rate when reading a large amount of data into a small direct CharBuffer. I don't know how common that is. We would introduce an instance variable for one path in one method.

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From plevart at openjdk.java.net  Mon Jan 18 08:57:43 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 18 Jan 2021 08:57:43 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
Message-ID: <66uDvXvRZ0UyNV93dFYWuQ-xp7GM-eVjCxsP-Aa0fMY=.46a98be7-25d9-4091-8db2-5b25beb5a9b1@github.com>

On Sat, 9 Jan 2021 23:06:22 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add unit tests
>   
>   - add unit test for Reader#read(CharBuffer)
>   - add unit test for InputStreamReader#reader(CharBuffer)
>   - test with both on-heap and off-heap buffers

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

> 205:                         target.put(cbuf, 0, n);
> 206:                         nread += n;
> 207:                         remaining -= n;

Wouldn't there be a possibility for target.put(cbuf, 0, n) to throw BufferOverflowException ?
For example:
- there's room (remaining) for TRANSFER_BUFFER_SIZE + 1 characters in target
- cbuff is sized to TRANSFER_BUFFER_SIZE
- 1st iteration of do loop transfers TRANSFER_BUFFER_SIZE charasters (remaining == 1)
- 2nd iteration reads > 1 (up to TRANSFER_BUFFER_SIZE) characters
- target.put throws BufferOverflowException

You have to limit the amount read in each iteration to be Math.min(remaining, cbuf.length)

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From alanb at openjdk.java.net  Mon Jan 18 09:07:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 18 Jan 2021 09:07:39 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe
In-Reply-To: <BPo7q4N63XdWEeqFpcvgjV-g466JXojOQTYku1pn6Qw=.f6e04ad0-8076-40b1-9a99-54bd7214bd11@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <l1XpPLhhm48_iBAmYhCo4XFp3lWQh9K-9CpvKVA_yL4=.cf1ee731-e826-4ebd-85dc-4238b357d901@github.com>
 <Mnm2ewxWHOv3Bbp1RvKrd_qdrjRx4y2D5s_v8_TfstE=.6437c1f1-4281-46ef-adcd-7b0972e117d6@github.com>
 <NM4-rB4SqUwAsAkYDQxDgTFLuaf1PPbxF7fohIukT5c=.437e5cd9-cca2-4737-87bb-51b950eac5be@github.com>
 <FQYcS9lMSTmDlmeAVXZPaXBRzX9HGhsFtwTOia-Fpss=.7ddb7d74-b76b-4c4e-822d-bf2b973f3f12@github.com>
 <pOYiGYq2J4OZehaYVyvZdATrqSsfv4s2tY7uyJ7n6H4=.9898136d-ec3b-4532-81de-568f2d91f8ed@github.com>
 <BPo7q4N63XdWEeqFpcvgjV-g466JXojOQTYku1pn6Qw=.f6e04ad0-8076-40b1-9a99-54bd7214bd11@github.com>
Message-ID: <ZJT7O-4ePd5OI3vzBy_bLISL1PbEkDjMXzoZuQDZQIk=.16962703-d027-4bc4-8c3b-39a6aec4a4b9@github.com>

On Fri, 15 Jan 2021 23:10:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Benchmark output for commit 3:
>> 
>> 1 fork, 5 10s warmup iterations, 10 10s measurement iterations, 1 thread
>> pipe wakeup
>> 
>> Result "org.sample.EventFDBench.test":
>>   674120.350 ?(99.9%) 2246.122 ops/s [Average]
>>   (min, avg, max) = (671278.574, 674120.350, 676866.600), stdev = 1485.671
>>   CI (99.9%): [671874.229, 676366.472] (assumes normal distribution)
>> 
>> Result "org.sample.EventFDBench.test":
>>   676831.218 ?(99.9%) 2353.488 ops/s [Average]
>>   (min, avg, max) = (673745.955, 676831.218, 678758.514), stdev = 1556.686
>>   CI (99.9%): [674477.731, 679184.706] (assumes normal distribution)
>> 
>> Result "org.sample.EventFDBench.test":
>>   675830.928 ?(99.9%) 3052.319 ops/s [Average]
>>   (min, avg, max) = (671286.540, 675830.928, 679293.739), stdev = 2018.920
>>   CI (99.9%): [672778.609, 678883.246] (assumes normal distribution)
>> 
>> eventfd wakeup
>> 
>> Result "org.sample.EventFDBench.test":
>>   698126.388 ?(99.9%) 2776.885 ops/s [Average]
>>   (min, avg, max) = (694253.565, 698126.388, 700086.784), stdev = 1836.738
>>   CI (99.9%): [695349.503, 700903.273] (assumes normal distribution)
>> 
>> Result "org.sample.EventFDBench.test":
>>   699992.095 ?(99.9%) 3653.650 ops/s [Average]
>>   (min, avg, max) = (695504.040, 699992.095, 702932.998), stdev = 2416.663
>>   CI (99.9%): [696338.445, 703645.746] (assumes normal distribution)
>> 
>> Result "org.sample.EventFDBench.test":
>>   702140.433 ?(99.9%) 3019.100 ops/s [Average]
>>   (min, avg, max) = (698291.810, 702140.433, 704818.744), stdev = 1996.948
>>   CI (99.9%): [699121.333, 705159.533] (assumes normal distribution)
>> 
>> 
>> 1 fork, 5 10s warmup iterations, 10 10s measurement iterations, 6 threads
>> pipe wakeup
>> 
>> Result "org.sample.EventFDBench.test":
>>   3223142.871 ?(99.9%) 94755.560 ops/s [Average]
>>   (min, avg, max) = (3120710.890, 3223142.871, 3283407.281), stdev = 62674.936
>>   CI (99.9%): [3128387.312, 3317898.431] (assumes normal distribution)
>> 
>> Result "org.sample.EventFDBench.test":
>>   3260747.260 ?(99.9%) 11514.840 ops/s [Average]
>>   (min, avg, max) = (3248875.268, 3260747.260, 3268729.421), stdev = 7616.354
>>   CI (99.9%): [3249232.419, 3272262.100] (assumes normal distribution)
>> 
>> Result "org.sample.EventFDBench.test":
>>   3243306.245 ?(99.9%) 56893.385 ops/s [Average]
>>   (min, avg, max) = (3160345.608, 3243306.245, 3277487.093), stdev = 37631.452
>>   CI (99.9%): [3186412.859, 3300199.630] (assumes normal distribution)
>> 
>> eventfd wakeup
>> 
>> Result "org.sample.EventFDBench.test":
>>   3340323.956 ?(99.9%) 38169.834 ops/s [Average]
>>   (min, avg, max) = (3280464.427, 3340323.956, 3355415.702), stdev = 25246.982
>>   CI (99.9%): [3302154.122, 3378493.790] (assumes normal distribution)
>> 
>> Result "org.sample.EventFDBench.test":
>>   3344287.954 ?(99.9%) 46249.831 ops/s [Average]
>>   (min, avg, max) = (3261670.180, 3344287.954, 3363007.332), stdev = 30591.400
>>   CI (99.9%): [3298038.123, 3390537.786] (assumes normal distribution)
>> 
>> Result "org.sample.EventFDBench.test":
>>   3353728.294 ?(99.9%) 40760.876 ops/s [Average]
>>   (min, avg, max) = (3285776.202, 3353728.294, 3372002.914), stdev = 26960.796
>>   CI (99.9%): [3312967.418, 3394489.170] (assumes normal distribution)
>
> Throughput improvement as measured by the benchmark looks to be a bit over 3% for eventfd wakeup with respect to pipe wakeup. The confidence intervals of the pipe wakeup results mostly do not overlap those of the corresponding eventfd wakeup results which tends to suggest some degree of reliability.
> 
> Summary of benchmark results:
> 1 fork, 5 10s warmup iterations, 10 10s measurement iterations, 1 thread
> pipe wakeup
> 
> Mean average: 675594.1653333333
> Max CI upper bound: 679184.706
> 
> eventfd wakeup
> 
> Mean average: 700086.3053333334
> Min CI lower bound: 695349.503
> Throughput change: +3.6%
> 
> 1 fork, 5 10s warmup iterations, 10 10s measurement iterations, 6 threads
> pipe wakeup
> 
> Mean average: 3242398.7919999994
> Max CI upper bound: 3317898.431
> 
> eventfd wakeup
> 
> Mean average: 3346113.4013333335
> Min CI lower bound: 3298038.123
> Throughput change: +3.2%

Are you going to include the micro benchmark in the patch? The presentation of the summary in the comments is hard to read but a 3% is okay. It was inconclusive when I tried a long time ago.

The updated patch looks better. IOUtil.write(fd, long) begs the question as to whether the 8 bytes for the long are written in big or little endian. I realise it doesn't matter for EventFD but we will need to get this right. I would be tempted to call evetnfd with the flags set to 0 and then use IOUtil.configureBlocking when we need it non-blocking.

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From ecki at zusammenkunft.net  Mon Jan 18 21:29:04 2021
From: ecki at zusammenkunft.net (Bernd)
Date: Mon, 18 Jan 2021 22:29:04 +0100
Subject: Java and the NTFS Path weakness
In-Reply-To: <CABOR3+zJ+P-G3=nDPAQpUqq_-Fy_mBy6zZD_qoebHKToOvThUA@mail.gmail.com>
References: <CABOR3+zJ+P-G3=nDPAQpUqq_-Fy_mBy6zZD_qoebHKToOvThUA@mail.gmail.com>
Message-ID: <CABOR3+wdCK-Pm+iLCBjbyi3gfUm5V-ZEVp_AdwWNozg9gES6VA@mail.gmail.com>

Hello,

bad news everyone. The second Windows Filesystem related security bug
reported by Jonas Lykkegaard which allows crashing Windows with a
unpriveledged read access also affects JVM and it is not filtered by
Path.of. Which means bot new File(bad).exists() and
Files.readAllLines(Path.of(bad)) will crash Windows immediatelly.

I verified this on the latest Windows Server 2019 January Security Update.

var bad = "\\\\.\\globalroot\\device\\condrv\\kernelconnect"

Gruss
Bernd


Am Mo., 18. Jan. 2021 um 01:39 Uhr schrieb Bernd <ecki at zusammenkunft.net>:

> Hello,
>
> you might have seen the media coverage on a Microsoft Windows 10 and
> Windows Server problem where a certain NTFS internal path causes the
> Windows driver to claim corruption and mark the filesystem dirty. (Some
> even reported actual corruption of their filesystems).
>
> The java.nio Path seems to be resistance against that, as it detects an
> illegal path itself:
>
> |  Welcome to JShell -- Version 11.0.9.1
> |  For an introduction type: /help intro
>
> jshell> var bad = "C:\\:$i30:$bitmap";
> bad ==> "C:\\:$i30:$bitmap"
>
> jshell> new File(bad).toPath()
> |  Exception java.nio.file.InvalidPathException: Illegal char <:> at index
> 3: C:\:$i30:$bitmap
> |        at WindowsPathParser.normalize (WindowsPathParser.java:182)
> |        at WindowsPathParser.parse (WindowsPathParser.java:153)
> |        at WindowsPathParser.parse (WindowsPathParser.java:77)
> |        at WindowsPath.parse (WindowsPath.java:92)
> |        at WindowsFileSystem.getPath (WindowsFileSystem.java:229)
> |        at File.toPath (File.java:2292)
> |        at (#6:1)
>
> jshell> Paths.get(bad)
> |  Exception java.nio.file.InvalidPathException: Illegal char <:> at index
> 3: C:\:$i30:$bitmap
> |        at WindowsPathParser.normalize (WindowsPathParser.java:182)
> |        at WindowsPathParser.parse (WindowsPathParser.java:153)
> |        at WindowsPathParser.parse (WindowsPathParser.java:77)
> |        at WindowsPath.parse (WindowsPath.java:92)
> |        at WindowsFileSystem.getPath (WindowsFileSystem.java:229)
> |        at Path.of (Path.java:147)
> |        at Paths.get (Paths.java:69)
> |        at (#7:1)
>
> jshell> Path.of(bad)
> |  Exception java.nio.file.InvalidPathException: Illegal char <:> at index
> 3: C:\:$i30:$bitmap
> |        at WindowsPathParser.normalize (WindowsPathParser.java:182)
> |        at WindowsPathParser.parse (WindowsPathParser.java:153)
> |        at WindowsPathParser.parse (WindowsPathParser.java:77)
> |        at WindowsPath.parse (WindowsPath.java:92)
> |        at WindowsFileSystem.getPath (WindowsFileSystem.java:229)
> |        at Path.of (Path.java:147)
> |        at (#8:1)
>
> (not sure if there is a way to construct a path without that
> normalization).
>
> Unfortunally, however, the java.io.File and its IO functions to not
> provide this protection, when you call
>
> jshell> new File(bad).exists()
> $9 ==> false
>
> (or some other methods accessing the file) you will see the crash message
> in the event log.
>
> I am not sure if Java should or could filter that (however since java.nio
> already does it might be an option, not sure however if Microsoft would be
> faster and fixing that problem). But I thought I mention this here in case
> you have Java server applications which derive file names from untrusted
> user input (including uncompressing ZIP files).
>
> Gruss
> Bernd
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210118/cc992de0/attachment.htm>

From redestad at openjdk.java.net  Tue Jan 19 00:51:09 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 00:51:09 GMT
Subject: RFR: 8259947: Optimize UnixPath.encode
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <tflq5p_kkFyt6IYz9AOsTehPOFVccnr-5yl8DZ0S2oI=.51ec7acd-1e05-4f9a-9e82-f842a98a8c5e@github.com>

On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

Microbenchmark results, baseline:
Benchmark                 Mode  Cnt     Score    Error  Units
FileToPath.mix            avgt   15  1669.996 ? 76.308  ns/op
FileToPath.normalized     avgt   15   349.300 ? 16.851  ns/op
FileToPath.notNormalized  avgt   15   553.013 ? 28.736  ns/op
FileToPath.trailingSlash  avgt   15   415.107 ? 18.322  ns/op

Target:
Benchmark                 Mode  Cnt    Score    Error  Units
FileToPath.mix            avgt   15  887.191 ? 34.167  ns/op
FileToPath.normalized     avgt   15  132.653 ?  2.907  ns/op
FileToPath.notNormalized  avgt   15  333.678 ? 17.665  ns/op
FileToPath.trailingSlash  avgt   15  192.272 ?  7.644  ns/op

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

PR: https://git.openjdk.java.net/jdk/pull/2135

From redestad at openjdk.java.net  Tue Jan 19 00:51:09 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 00:51:09 GMT
Subject: RFR: 8259947: Optimize UnixPath.encode
Message-ID: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>

This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.

This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

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

Commit messages:
 - Add micro. To properly examine cost of toPath() needs a new File due caching - use FileOpen as a baseline
 - Optimize UnixPath.encode

Changes: https://git.openjdk.java.net/jdk/pull/2135/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2135&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259947
  Stats: 138 lines in 6 files changed: 79 ins; 45 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2135/head:pull/2135

PR: https://git.openjdk.java.net/jdk/pull/2135

From github.com+471021+marschall at openjdk.java.net  Tue Jan 19 07:25:51 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 19 Jan 2021 07:25:51 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <66uDvXvRZ0UyNV93dFYWuQ-xp7GM-eVjCxsP-Aa0fMY=.46a98be7-25d9-4091-8db2-5b25beb5a9b1@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
 <66uDvXvRZ0UyNV93dFYWuQ-xp7GM-eVjCxsP-Aa0fMY=.46a98be7-25d9-4091-8db2-5b25beb5a9b1@github.com>
Message-ID: <TujK1flvtJ144KxV3OE5JgwAbQ6X4GRS8EWuskcE_A0=.786a8094-0066-4012-abfb-dc0f97b0f9f8@github.com>

On Mon, 18 Jan 2021 07:47:30 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add unit tests
>>   
>>   - add unit test for Reader#read(CharBuffer)
>>   - add unit test for InputStreamReader#reader(CharBuffer)
>>   - test with both on-heap and off-heap buffers
>
> src/java.base/share/classes/java/io/Reader.java line 207:
> 
>> 205:                         target.put(cbuf, 0, n);
>> 206:                         nread += n;
>> 207:                         remaining -= n;
> 
> Wouldn't there be a possibility for target.put(cbuf, 0, n) to throw BufferOverflowException ?
> For example:
> - there's room (remaining) for TRANSFER_BUFFER_SIZE + 1 characters in target
> - cbuff is sized to TRANSFER_BUFFER_SIZE
> - 1st iteration of do loop transfers TRANSFER_BUFFER_SIZE charasters (remaining == 1)
> - 2nd iteration reads > 1 (up to TRANSFER_BUFFER_SIZE) characters
> - target.put throws BufferOverflowException
> 
> You have to limit the amount read in each iteration to be Math.min(remaining, cbuf.length)

You're correct. I need to expand the unit tests.

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From Alan.Bateman at oracle.com  Tue Jan 19 08:26:02 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 19 Jan 2021 08:26:02 +0000
Subject: Java and the NTFS Path weakness
In-Reply-To: <CABOR3+wdCK-Pm+iLCBjbyi3gfUm5V-ZEVp_AdwWNozg9gES6VA@mail.gmail.com>
References: <CABOR3+zJ+P-G3=nDPAQpUqq_-Fy_mBy6zZD_qoebHKToOvThUA@mail.gmail.com>
 <CABOR3+wdCK-Pm+iLCBjbyi3gfUm5V-ZEVp_AdwWNozg9gES6VA@mail.gmail.com>
Message-ID: <18c73acc-32ed-6688-4a1c-bf3e0dfa73e5@oracle.com>



On 18/01/2021 21:29, Bernd wrote:
> Hello,
>
> bad news everyone. The second Windows Filesystem related security bug 
> reported by Jonas Lykkegaard which allows crashing Windows with a 
> unpriveledged read access also affects JVM and it is not filtered by 
> Path.of. Which means bot new File(bad).exists() and 
> Files.readAllLines(Path.of(bad)) will crash Windows immediatelly.
>
> I verified this on the latest Windows Server 2019 January Security Update.
>
> var bad = "\\\\.\\globalroot\\device\\condrv\\kernelconnect"
>
BSOD issues should be reported to Microsoft. If there is any suggestion 
of a JDK bug here then it should be reported to 
vuln-report at openjdk.java.net. We (at least Oracle engineers) cannot 
engage in any discussion of vulnerability issues here.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210119/4db57286/attachment.htm>

From chegar at openjdk.java.net  Tue Jan 19 09:43:49 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 19 Jan 2021 09:43:49 GMT
Subject: RFR: 8259947: Optimize UnixPath.encode
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <pm5cTuqLJMmimY2Cts0Z5Us6OnG93_klR-K_GtJyCLw=.4924ce46-d0f7-4eaa-bfad-8388f0957ec0@github.com>

On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

I think that this looks good ( I had a similar thought when looking through this code recently, for a separate issue ).

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

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2135

From shade at openjdk.java.net  Tue Jan 19 10:49:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 19 Jan 2021 10:49:51 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <RyEqdGAvWz7AUu97qVlZ0PCHtW_r4bWEJxZlprVoW2k=.625a8a67-cf9c-4a80-9684-2d6b574d9db1@github.com>

On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

Changes requested by shade (Reviewer).

test/micro/org/openjdk/bench/java/io/FileToPath.java line 53:

> 51:         bh.consume(new File(normalFile).toPath());
> 52:         bh.consume(new File(trailingSlash).toPath());
> 53:         bh.consume(new File(root).toPath());

No singular test for `new File(root)`, but here it is in the `mix` anyway? What would probably be not comparable.

test/micro/org/openjdk/bench/java/io/FileToPath.java line 46:

> 44:     public String root = "/";
> 45:     public String trailingSlash = "/test/dir/file/name.txt/";
> 46:     public String notNormalizedFile = "/test/dir/file//name.txt";

Can be `private`, I think. As long as those are not `static final`...

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

PR: https://git.openjdk.java.net/jdk/pull/2135

From redestad at openjdk.java.net  Tue Jan 19 11:38:52 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 11:38:52 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation
In-Reply-To: <RyEqdGAvWz7AUu97qVlZ0PCHtW_r4bWEJxZlprVoW2k=.625a8a67-cf9c-4a80-9684-2d6b574d9db1@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <RyEqdGAvWz7AUu97qVlZ0PCHtW_r4bWEJxZlprVoW2k=.625a8a67-cf9c-4a80-9684-2d6b574d9db1@github.com>
Message-ID: <8GiNtg22GuKwPVCJIb6WWSMIH-eoxKt_pqutmgyFHwQ=.8407fccf-7a4a-47e4-815c-b76d64dad098@github.com>

On Tue, 19 Jan 2021 10:46:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> test/micro/org/openjdk/bench/java/io/FileToPath.java line 46:
> 
>> 44:     public String root = "/";
>> 45:     public String trailingSlash = "/test/dir/file/name.txt/";
>> 46:     public String notNormalizedFile = "/test/dir/file//name.txt";
> 
> Can be `private`, I think. As long as those are not `static final`...

Agree this can be cleaned up.

The micro was derived/copied from the `FileOpen` micro in the same package, so comments apply to a pre-existing micro. I'll refactor this to be a subclass inside that micro and clean up both.

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

PR: https://git.openjdk.java.net/jdk/pull/2135

From redestad at openjdk.java.net  Tue Jan 19 12:02:13 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 12:02:13 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v2]
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <CS9fXniQ8jR33MsMwEMhKfBwZKEVHEV30iAL-6oD8eY=.56996ab9-e651-4f33-88a6-2313995910a2@github.com>

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

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

  Fold ToPath into FileOpen, add root benchmarks to keep mix comparable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2135/files
  - new: https://git.openjdk.java.net/jdk/pull/2135/files/27a55ee0..18c3105b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2135&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2135&range=00-01

  Stats: 128 lines in 2 files changed: 50 ins; 72 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2135/head:pull/2135

PR: https://git.openjdk.java.net/jdk/pull/2135

From alanb at openjdk.java.net  Tue Jan 19 12:16:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Jan 2021 12:16:41 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v2]
In-Reply-To: <CS9fXniQ8jR33MsMwEMhKfBwZKEVHEV30iAL-6oD8eY=.56996ab9-e651-4f33-88a6-2313995910a2@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <CS9fXniQ8jR33MsMwEMhKfBwZKEVHEV30iAL-6oD8eY=.56996ab9-e651-4f33-88a6-2313995910a2@github.com>
Message-ID: <oyHwLSs6BIqyMxzejkoWiYmQvn60soG8f05Y_ih7ri0=.ba00e5b8-df4a-46b0-a1ab-b111090b7484@github.com>

On Tue, 19 Jan 2021 12:02:13 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fold ToPath into FileOpen, add root benchmarks to keep mix comparable

src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 118:

> 116:         try {
> 117:             return JLA.getBytesNoRepl(input, Util.jnuEncoding());
> 118:         } catch (CharacterCodingException cce) {

The encode method pre-dates JLA.getBytesNoRepl and the recent optimisations so this is a good cleanup.

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

PR: https://git.openjdk.java.net/jdk/pull/2135

From alanb at openjdk.java.net  Tue Jan 19 12:13:51 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Jan 2021 12:13:51 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v2]
In-Reply-To: <CS9fXniQ8jR33MsMwEMhKfBwZKEVHEV30iAL-6oD8eY=.56996ab9-e651-4f33-88a6-2313995910a2@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <CS9fXniQ8jR33MsMwEMhKfBwZKEVHEV30iAL-6oD8eY=.56996ab9-e651-4f33-88a6-2313995910a2@github.com>
Message-ID: <6Xl4r1XwRIaAo-NW3vrTyzfmh5wW_w0uNphsZseTxSE=.1412df8d-065e-44a8-ab0d-b7f9f6cc8eba@github.com>

On Tue, 19 Jan 2021 12:02:13 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fold ToPath into FileOpen, add root benchmarks to keep mix comparable

src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 112:

> 110:     private static final jdk.internal.access.JavaLangAccess JLA =
> 111:             jdk.internal.access.SharedSecrets.getJavaLangAccess();
> 112: 

Can you move this to the top, before the instance fields? Also let's import the jdk.internal.acces classes rather than using fully qualified names. That will keep it consistent with the existing code in this area.

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

PR: https://git.openjdk.java.net/jdk/pull/2135

From redestad at openjdk.java.net  Tue Jan 19 12:26:08 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Jan 2021 12:26:08 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

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

  Move JLA to top, add imports

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2135/files
  - new: https://git.openjdk.java.net/jdk/pull/2135/files/18c3105b..b023c0a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2135&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2135&range=01-02

  Stats: 8 lines in 1 file changed: 5 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2135/head:pull/2135

PR: https://git.openjdk.java.net/jdk/pull/2135

From alanb at openjdk.java.net  Tue Jan 19 13:05:50 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Jan 2021 13:05:50 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]
In-Reply-To: <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>
Message-ID: <HDpY17yT1Wu3CAnYVxHDN8VSmWiKsBAPN2bo_I-8quc=.2b939a7b-dca2-42f8-ab1f-ff71027d4488@github.com>

On Tue, 19 Jan 2021 12:26:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move JLA to top, add imports

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2135

From bpb at openjdk.java.net  Tue Jan 19 21:56:18 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 19 Jan 2021 21:56:18 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v4]
In-Reply-To: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
Message-ID: <pKdnpQV3t4ymxEJdosU7avDQZm-RH6xL1YidIppcw6c=.2b038d28-c2b9-438f-a2ee-0ef4b065474b@github.com>

> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.

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

 - 8253478: jcheck cleanup
 - 8253478: Add micro benchmark, revert IOUtil.write(int,long) addition, reinstate EventFD.set0(), use IOUtil.configureBlocking().

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2082/files
  - new: https://git.openjdk.java.net/jdk/pull/2082/files/8a95f23f..3eca0738

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=02-03

  Stats: 93 lines in 5 files changed: 80 ins; 9 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2082.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2082/head:pull/2082

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Tue Jan 19 21:59:13 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 19 Jan 2021 21:59:13 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v5]
In-Reply-To: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
Message-ID: <cAVMdIAmoU8Lbpf144k7lGdNqimmIcEKHqfhXsDq-dk=.f62b430b-0b04-496a-a670-665ec1e59553@github.com>

> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.

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

  8253478: clean up comment in micro

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2082/files
  - new: https://git.openjdk.java.net/jdk/pull/2082/files/3eca0738..839873bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Tue Jan 19 22:24:48 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 19 Jan 2021 22:24:48 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe
In-Reply-To: <ZJT7O-4ePd5OI3vzBy_bLISL1PbEkDjMXzoZuQDZQIk=.16962703-d027-4bc4-8c3b-39a6aec4a4b9@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <l1XpPLhhm48_iBAmYhCo4XFp3lWQh9K-9CpvKVA_yL4=.cf1ee731-e826-4ebd-85dc-4238b357d901@github.com>
 <Mnm2ewxWHOv3Bbp1RvKrd_qdrjRx4y2D5s_v8_TfstE=.6437c1f1-4281-46ef-adcd-7b0972e117d6@github.com>
 <NM4-rB4SqUwAsAkYDQxDgTFLuaf1PPbxF7fohIukT5c=.437e5cd9-cca2-4737-87bb-51b950eac5be@github.com>
 <FQYcS9lMSTmDlmeAVXZPaXBRzX9HGhsFtwTOia-Fpss=.7ddb7d74-b76b-4c4e-822d-bf2b973f3f12@github.com>
 <pOYiGYq2J4OZehaYVyvZdATrqSsfv4s2tY7uyJ7n6H4=.9898136d-ec3b-4532-81de-568f2d91f8ed@github.com>
 <BPo7q4N63XdWEeqFpcvgjV-g466JXojOQTYku1pn6Qw=.f6e04ad0-8076-40b1-9a99-54bd7214bd11@github.com>
 <ZJT7O-4ePd5OI3vzBy_bLISL1PbEkDjMXzoZuQDZQIk=.16962703-d027-4bc4-8c3b-39a6aec4a4b9@github.com>
Message-ID: <RvxrDF0AZak_kY_j2LmSl9Y8-fvBhFScYy8gY35z0zI=.a8b3ff37-9ee7-4da9-876c-abb00af97bce@github.com>

On Mon, 18 Jan 2021 09:04:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Throughput improvement as measured by the benchmark looks to be a bit over 3% for eventfd wakeup with respect to pipe wakeup. The confidence intervals of the pipe wakeup results mostly do not overlap those of the corresponding eventfd wakeup results which tends to suggest some degree of reliability.
>> 
>> Summary of benchmark results:
>> 1 fork, 5 10s warmup iterations, 10 10s measurement iterations, 1 thread
>> pipe wakeup
>> 
>> Mean average: 675594.1653333333
>> Max CI upper bound: 679184.706
>> 
>> eventfd wakeup
>> 
>> Mean average: 700086.3053333334
>> Min CI lower bound: 695349.503
>> Throughput change: +3.6%
>> 
>> 1 fork, 5 10s warmup iterations, 10 10s measurement iterations, 6 threads
>> pipe wakeup
>> 
>> Mean average: 3242398.7919999994
>> Max CI upper bound: 3317898.431
>> 
>> eventfd wakeup
>> 
>> Mean average: 3346113.4013333335
>> Min CI lower bound: 3298038.123
>> Throughput change: +3.2%
>
> Are you going to include the micro benchmark in the patch? The presentation of the summary in the comments is hard to read but a 3% is okay. It was inconclusive when I tried a long time ago.
> 
> The updated patch looks better. IOUtil.write(fd, long) begs the question as to whether the 8 bytes for the long are written in big or little endian. I realise it doesn't matter for EventFD but we will need to get this right. I would be tempted to call evetnfd with the flags set to 0 and then use IOUtil.configureBlocking when we need it non-blocking.

Updated the patch to:
- include the micro benchmark,
- create the `eventfd` with zero initial value and flags,
- use `IOUtil.configureBlocking()` to set the `eventfd` to non-blocking,
- remove the addition of `IOUtil.write(int fd, long value)` and its use in `EventFD.set()`,
- add `EventFD.set0()` and use it in `EventFD.set()`.

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From rpaquay at google.com  Tue Jan 19 22:36:44 2021
From: rpaquay at google.com (Renaud Paquay)
Date: Tue, 19 Jan 2021 14:36:44 -0800
Subject: JDK-8259873: (fs) Add
 java.nio.file.attribute.BasicWithKeyFileAttributeView interface
Message-ID: <CAFcJ+g6pL_3fUaCAQU+59QcOVSaGc-HrcyBEAW4hjpVvL0OGoQ@mail.gmail.com>

As per comment in JDK-8259873
<https://bugs.openjdk.java.net/browse/JDK-8259873>, I am starting a
discussion topic for the proposed change in
https://github.com/openjdk/jdk/pull/2121.

Some context: The change, along with
https://github.com/openjdk/jdk/pull/2122, is about improving performance of
Files.walkFileTree on the Windows platform.

PR 2122
=======

PR 2122 is an "in place" (i.e. no behavior or public API change)
implementation change in WindowsDirectoryStream: Instead of using
FindFirstFile
<https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew>
,FindNextFile
<https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findnextfilew>,
the new implementation uses NtQueryDirectoryFile
<https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntquerydirectoryfile>,
which is more efficient at enumerating directory entries and allows
acquiring file keys for "free" with each entry.

With a file key available, Files.walkFileTree can implement symlink loop
detection very efficiently (comparing 2 file keys in memory), as opposed to
calling Files.isSameFile which incurs 2 file I/O on Windows (see code here
in FileTreeWalker here:
https://github.com/openjdk/jdk/blob/05a764f4ffb8030d6b768f2d362c388e5aabd92d/src/java.base/share/classes/java/nio/file/FileTreeWalker.java#L241
)

PR 2121
=======

PR 2121 (the subject of this email) is about removing one remaining call to
"isSameFile" in FileTreeWalker: The initial directory (this.dir) is part of
the stack of directories used for loop detection in the wouldLoop
<https://github.com/openjdk/jdk/blob/05a764f4ffb8030d6b768f2d362c388e5aabd92d/src/java.base/share/classes/java/nio/file/FileTreeWalker.java#L236>
method.
The goal of the change is to ensure there is a file key available for that
initial directory so that there is never a call made to "isSameFile".

With change 2122, *all* entries have a file key (in virtue of being
retrieved with NtQueryDirectoryInformation), *except* for the "this.dir"
entry (because that initial directory is provided by the caller of the API).

The problem is then how do we allow FileTreeWalker to retrieve the file key
for the initial directory.

Option 1: Change Files.readAttributes(file, BasicFileAttributes.class,
linkOptions) on Windows to always retrieve a file key.

The current implementation
<https://github.com/openjdk/jdk/blob/6948456dbf76bf314f17f24040c778a2d36a4431/src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java#L296>
uses GetFileAttributes
<https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileattributesw>
which
does *not* provide a file key. To get a file key, the implementation would
need to call GetFileInformationByHandle
<https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileinformationbyhandle>
(see
https://github.com/openjdk/jdk/blob/6948456dbf76bf314f17f24040c778a2d36a4431/src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java#L270).
Unfortunately, GetFileInformationByHandle is at least an order of magnitude
slower than GetFileAttributes, so it does not seem appropriate to slow down
all callers, including those who don't need a file key.

Option 2: Find a way for FileTreeWalker to give a "hint" to the file system
provider that its implementation would benefit from having a file key
available to file equality detection purposes, even if it means using a
slower implementation.

This is why PR 2121 introduces a new "BasicWithKeyFileAttributeView"
interface. FileTreeWalker queries the file system provider using this new
interface, hinting that it would like to obtain a file ket even if there is
some performance penalty. The main issue with this option is that it
introduces a new public type. One benefit is that it is a general purpose
API that could benefit other consumers (other than FileTreeWalker). AFAIK,
it is currently not possible for a consumer to ask for a file key
explicitly (consumers gets them for free on Linux, and never gets them on
Windows).

Option 3: Create a Windows specific version of FileTreeWalker that calls
directly into the WindowsFileProvider to obtain the file key.

The pro here is that there is no new public type, with the cons that we'd
have to create a windows specific version of FileTreeWalker, which is
currently platform agnostic.

PR 2121 currently implements option 2.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210119/3238e682/attachment.htm>

From michaelm at openjdk.java.net  Tue Jan 19 23:01:56 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 19 Jan 2021 23:01:56 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v5]
In-Reply-To: <cAVMdIAmoU8Lbpf144k7lGdNqimmIcEKHqfhXsDq-dk=.f62b430b-0b04-496a-a670-665ec1e59553@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <cAVMdIAmoU8Lbpf144k7lGdNqimmIcEKHqfhXsDq-dk=.f62b430b-0b04-496a-a670-665ec1e59553@github.com>
Message-ID: <dkNaZ3j8n7dW7eApQbCw0dC5UGa2IbfuppavKbZ9RbI=.b84b987f-90c1-43c4-af51-522d5ca1571e@github.com>

On Tue, 19 Jan 2021 21:59:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253478: clean up comment in micro

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 89:

> 87:         }
> 88: 
> 89:         // register one end of the socket pair for wakeups

I guess the comment at line 89 no longer applies.

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Tue Jan 19 23:18:50 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 19 Jan 2021 23:18:50 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v5]
In-Reply-To: <dkNaZ3j8n7dW7eApQbCw0dC5UGa2IbfuppavKbZ9RbI=.b84b987f-90c1-43c4-af51-522d5ca1571e@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <cAVMdIAmoU8Lbpf144k7lGdNqimmIcEKHqfhXsDq-dk=.f62b430b-0b04-496a-a670-665ec1e59553@github.com>
 <dkNaZ3j8n7dW7eApQbCw0dC5UGa2IbfuppavKbZ9RbI=.b84b987f-90c1-43c4-af51-522d5ca1571e@github.com>
Message-ID: <R0KTaaeQCKu5vetEJchZqg6m805nXrRKzkeUy_8931E=.4e99aca2-4bcc-450e-aa76-26d8698dc710@github.com>

On Tue, 19 Jan 2021 22:58:52 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8253478: clean up comment in micro
>
> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 89:
> 
>> 87:         }
>> 88: 
>> 89:         // register one end of the socket pair for wakeups
> 
> I guess the comment at line 89 no longer applies.

You are correct, thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Tue Jan 19 23:29:09 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 19 Jan 2021 23:29:09 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v6]
In-Reply-To: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
Message-ID: <Do5ypkkC4YyQUpwt6XU3IjE1cv2DnfRlx63j3xOVFJ4=.b6d8829c-8974-4448-8db7-1d2d57b9abd3@github.com>

> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.

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

  8253478: clean up comment in epoll selector

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2082/files
  - new: https://git.openjdk.java.net/jdk/pull/2082/files/839873bd..b231c536

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=04-05

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From martinrb at google.com  Wed Jan 20 07:55:24 2021
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 19 Jan 2021 23:55:24 -0800
Subject: JDK-8259873: (fs) Add
 java.nio.file.attribute.BasicWithKeyFileAttributeView interface
In-Reply-To: <CAFcJ+g6pL_3fUaCAQU+59QcOVSaGc-HrcyBEAW4hjpVvL0OGoQ@mail.gmail.com>
References: <CAFcJ+g6pL_3fUaCAQU+59QcOVSaGc-HrcyBEAW4hjpVvL0OGoQ@mail.gmail.com>
Message-ID: <CA+kOe09mm9h6M5F2B4v3bzNX6VPE+4xAHQ2Gjs0JFfnsza=b0A@mail.gmail.com>

I'm mostly cheerleading here, and haven't developed for Windows in many
years, but ... I agree with the strategy here.  More use of file keys would
benefit performance on all platforms.  OTOH I worry that filekeys are
inconsistently implemented on different OSes and filesystems.

On Tue, Jan 19, 2021 at 2:36 PM Renaud Paquay <rpaquay at google.com> wrote:

> As per comment in JDK-8259873
> <https://bugs.openjdk.java.net/browse/JDK-8259873>, I am starting a
> discussion topic for the proposed change in
> https://github.com/openjdk/jdk/pull/2121.
>
> Some context: The change, along with
> https://github.com/openjdk/jdk/pull/2122, is about improving performance
> of Files.walkFileTree on the Windows platform.
>
> PR 2122
> =======
>
> PR 2122 is an "in place" (i.e. no behavior or public API change)
> implementation change in WindowsDirectoryStream: Instead of using
> FindFirstFile
> <https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew>
> ,FindNextFile
> <https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findnextfilew>,
> the new implementation uses NtQueryDirectoryFile
> <https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntquerydirectoryfile>,
> which is more efficient at enumerating directory entries and allows
> acquiring file keys for "free" with each entry.
>
> With a file key available, Files.walkFileTree can implement symlink loop
> detection very efficiently (comparing 2 file keys in memory), as opposed to
> calling Files.isSameFile which incurs 2 file I/O on Windows (see code here
> in FileTreeWalker here:
> https://github.com/openjdk/jdk/blob/05a764f4ffb8030d6b768f2d362c388e5aabd92d/src/java.base/share/classes/java/nio/file/FileTreeWalker.java#L241
> )
>
> PR 2121
> =======
>
> PR 2121 (the subject of this email) is about removing one remaining call
> to "isSameFile" in FileTreeWalker: The initial directory (this.dir) is
> part of the stack of directories used for loop detection in the wouldLoop
> <https://github.com/openjdk/jdk/blob/05a764f4ffb8030d6b768f2d362c388e5aabd92d/src/java.base/share/classes/java/nio/file/FileTreeWalker.java#L236> method.
> The goal of the change is to ensure there is a file key available for that
> initial directory so that there is never a call made to "isSameFile".
>
> With change 2122, *all* entries have a file key (in virtue of being
> retrieved with NtQueryDirectoryInformation), *except* for the "this.dir"
> entry (because that initial directory is provided by the caller of the API).
>
> The problem is then how do we allow FileTreeWalker to retrieve the file
> key for the initial directory.
>
> Option 1: Change Files.readAttributes(file, BasicFileAttributes.class,
> linkOptions) on Windows to always retrieve a file key.
>
> The current implementation
> <https://github.com/openjdk/jdk/blob/6948456dbf76bf314f17f24040c778a2d36a4431/src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java#L296>
> uses GetFileAttributes
> <https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileattributesw> which
> does *not* provide a file key. To get a file key, the implementation would
> need to call GetFileInformationByHandle
> <https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileinformationbyhandle>
> (see
> https://github.com/openjdk/jdk/blob/6948456dbf76bf314f17f24040c778a2d36a4431/src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java#L270).
> Unfortunately, GetFileInformationByHandle is at least an order of magnitude
> slower than GetFileAttributes, so it does not seem appropriate to slow down
> all callers, including those who don't need a file key.
>
> Option 2: Find a way for FileTreeWalker to give a "hint" to the file
> system provider that its implementation would benefit from having a file
> key available to file equality detection purposes, even if it means using a
> slower implementation.
>
> This is why PR 2121 introduces a new "BasicWithKeyFileAttributeView"
> interface. FileTreeWalker queries the file system provider using this new
> interface, hinting that it would like to obtain a file ket even if there is
> some performance penalty. The main issue with this option is that it
> introduces a new public type. One benefit is that it is a general purpose
> API that could benefit other consumers (other than FileTreeWalker). AFAIK,
> it is currently not possible for a consumer to ask for a file key
> explicitly (consumers gets them for free on Linux, and never gets them on
> Windows).
>
> Option 3: Create a Windows specific version of FileTreeWalker that calls
> directly into the WindowsFileProvider to obtain the file key.
>
> The pro here is that there is no new public type, with the cons that we'd
> have to create a windows specific version of FileTreeWalker, which is
> currently platform agnostic.
>
> PR 2121 currently implements option 2.
>
> Thoughts?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210119/d796baa6/attachment.htm>

From Alan.Bateman at oracle.com  Wed Jan 20 08:14:31 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 20 Jan 2021 08:14:31 +0000
Subject: JDK-8259873: (fs) Add
 java.nio.file.attribute.BasicWithKeyFileAttributeView interface
In-Reply-To: <CA+kOe09mm9h6M5F2B4v3bzNX6VPE+4xAHQ2Gjs0JFfnsza=b0A@mail.gmail.com>
References: <CAFcJ+g6pL_3fUaCAQU+59QcOVSaGc-HrcyBEAW4hjpVvL0OGoQ@mail.gmail.com>
 <CA+kOe09mm9h6M5F2B4v3bzNX6VPE+4xAHQ2Gjs0JFfnsza=b0A@mail.gmail.com>
Message-ID: <8ddd315d-ad8e-7fd6-2189-087266f6569a@oracle.com>

On 20/01/2021 07:55, Martin Buchholz wrote:
> I'm mostly cheerleading here, and haven't developed for Windows in 
> many years, but ... I agree with the strategy here.? More use of file 
> keys would benefit performance on all platforms.? OTOH I worry that 
> filekeys?are inconsistently implemented on different OSes and filesystems.
>
The recent thread with subject line "Files.isSameFile(Path,Path)" may be 
useful to re-read. The JDK has been using the volume serial number and 
file indexes but they are problematic on some volumes (not guarantee to 
be unique, maybe be zero). The Microsoft folks here have been looking to 
replace the usage with the "full path" (the approximate equivalent to 
realpath).

We did a lot work in JDK 7 to make the default case (not following sym 
links) be efficient on Windows. This is the reason for the internal 
BasicFileAttribuetHolder that FileTreeWalker uses to avoid needing to 
read the file attributes. Maybe we could lean on that internal interface 
and try to find options there before adding to the standard API.

Switching from FindFirstFile/FindNextFile to NtQueryDirectoryInformation 
is definitely worth exploring, it will just take significant time to 
review and will likely go through a few review iterations.

-Alan


From redestad at openjdk.java.net  Wed Jan 20 13:31:58 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 13:31:58 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]
In-Reply-To: <RyEqdGAvWz7AUu97qVlZ0PCHtW_r4bWEJxZlprVoW2k=.625a8a67-cf9c-4a80-9684-2d6b574d9db1@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <RyEqdGAvWz7AUu97qVlZ0PCHtW_r4bWEJxZlprVoW2k=.625a8a67-cf9c-4a80-9684-2d6b574d9db1@github.com>
Message-ID: <T4msQBKUKtwBZl7IsHKlMJuatDWbQeGR4fTBAHDjSyM=.6073e41f-6fbb-4683-8eba-e83a0af8cbde@github.com>

On Tue, 19 Jan 2021 10:46:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move JLA to top, add imports
>
> test/micro/org/openjdk/bench/java/io/FileToPath.java line 46:
> 
>> 44:     public String root = "/";
>> 45:     public String trailingSlash = "/test/dir/file/name.txt/";
>> 46:     public String notNormalizedFile = "/test/dir/file//name.txt";
> 
> Can be `private`, I think. As long as those are not `static final`...

@shipilev - are you OK with the updated micro?

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

PR: https://git.openjdk.java.net/jdk/pull/2135

From shade at openjdk.java.net  Wed Jan 20 14:08:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 20 Jan 2021 14:08:57 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]
In-Reply-To: <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>
Message-ID: <eJ2clS1kO43xmTzOx6FzfHixIRAh3Z8pwmMQtrQSHMg=.e0cc2751-fec7-444e-ac94-630e096bb7a4@github.com>

On Tue, 19 Jan 2021 12:26:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move JLA to top, add imports

test/micro/org/openjdk/bench/java/io/FileOpen.java line 103:

> 101:     @Warmup(time=2, iterations=5)
> 102:     @Measurement(time=3, iterations=5)
> 103:     @Fork(value=2, jvmArgs="-Xmx1g")

I thought this can be inherited from the enclosing benchmark.

test/micro/org/openjdk/bench/java/io/FileOpen.java line 104:

> 102:     @Measurement(time=3, iterations=5)
> 103:     @Fork(value=2, jvmArgs="-Xmx1g")
> 104:     public static class ToPath {

Do we really have to nest this test? It seems to gain nothing per se: the annotations and fields are still pretty much duplicated.

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

PR: https://git.openjdk.java.net/jdk/pull/2135

From redestad at openjdk.java.net  Wed Jan 20 15:11:16 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 15:11:16 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v4]
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <R6INRC1aTHZPpVvEzPkCwCM6myPkNlBn4S0aO9aAZEw=.8de2a474-78d2-44cc-871b-2f51854e7b46@github.com>

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

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

 - Merge branch 'master' into unix_encode
 - Move FileOpen.ToPath micros into top class
 - Move JLA to top, add imports
 - Fold ToPath into FileOpen, add root benchmarks to keep mix comparable
 - Add micro. To properly examine cost of toPath() needs a new File due caching - use FileOpen as a baseline
 - Optimize UnixPath.encode

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2135/files
  - new: https://git.openjdk.java.net/jdk/pull/2135/files/b023c0a5..98c76192

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2135&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2135&range=02-03

  Stats: 3891 lines in 128 files changed: 671 ins; 2864 del; 356 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2135/head:pull/2135

PR: https://git.openjdk.java.net/jdk/pull/2135

From shade at openjdk.java.net  Wed Jan 20 15:11:20 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 20 Jan 2021 15:11:20 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v4]
In-Reply-To: <R6INRC1aTHZPpVvEzPkCwCM6myPkNlBn4S0aO9aAZEw=.8de2a474-78d2-44cc-871b-2f51854e7b46@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <R6INRC1aTHZPpVvEzPkCwCM6myPkNlBn4S0aO9aAZEw=.8de2a474-78d2-44cc-871b-2f51854e7b46@github.com>
Message-ID: <7w5Qzm2c0-0Xfh_CXDqTw68oMgJ9fbiwNs9DuPRTQD4=.3b77841e-e04a-4612-845b-7600a42d83f0@github.com>

On Wed, 20 Jan 2021 15:08:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>> 
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into unix_encode
>  - Move FileOpen.ToPath micros into top class
>  - Move JLA to top, add imports
>  - Fold ToPath into FileOpen, add root benchmarks to keep mix comparable
>  - Add micro. To properly examine cost of toPath() needs a new File due caching - use FileOpen as a baseline
>  - Optimize UnixPath.encode

Marked as reviewed by shade (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2135

From redestad at openjdk.java.net  Wed Jan 20 15:17:55 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 15:17:55 GMT
Subject: Integrated: 8259947: (fs) Optimize UnixPath.encode implementation
In-Reply-To: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
Message-ID: <ISRsFJtKLYH-AeLWLMReHwX2ZPzQXFk8TXO3X2B10BU=.6f6d1d16-f81f-4774-8db6-d13b3a027226@github.com>

On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
> 
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.

This pull request has now been integrated.

Changeset: 5891509d
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5891509d
Stats:     107 lines in 6 files changed: 40 ins; 43 del; 24 mod

8259947: (fs) Optimize UnixPath.encode implementation

Reviewed-by: chegar, shade, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/2135

From redestad at openjdk.java.net  Wed Jan 20 15:17:54 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 20 Jan 2021 15:17:54 GMT
Subject: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]
In-Reply-To: <eJ2clS1kO43xmTzOx6FzfHixIRAh3Z8pwmMQtrQSHMg=.e0cc2751-fec7-444e-ac94-630e096bb7a4@github.com>
References: <OoptF4gzQyDn2JIDuBaxpfr9di3DorukQ2-GYD4agEg=.16c4eaf8-b880-4e7f-8dd4-8cd89ef1d752@github.com>
 <1s1c4bBy5zRlzjUrdJ3Bbly4nb3Q3EpbWJ6ruZenqcY=.3642563d-f891-4f65-8193-8e8b2190a151@github.com>
 <eJ2clS1kO43xmTzOx6FzfHixIRAh3Z8pwmMQtrQSHMg=.e0cc2751-fec7-444e-ac94-630e096bb7a4@github.com>
Message-ID: <KaojPYXcXRZlWfrnhvEVxS7rh64o2sDG5vh60l4oY6s=.623e6598-b186-47be-b75b-d26a5d4ac614@github.com>

On Wed, 20 Jan 2021 13:33:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move JLA to top, add imports
>
> test/micro/org/openjdk/bench/java/io/FileOpen.java line 103:
> 
>> 101:     @Warmup(time=2, iterations=5)
>> 102:     @Measurement(time=3, iterations=5)
>> 103:     @Fork(value=2, jvmArgs="-Xmx1g")
> 
> I thought this can be inherited from the enclosing benchmark.

Maybe it's only @State that doesn't inherit.

> test/micro/org/openjdk/bench/java/io/FileOpen.java line 104:
> 
>> 102:     @Measurement(time=3, iterations=5)
>> 103:     @Fork(value=2, jvmArgs="-Xmx1g")
>> 104:     public static class ToPath {
> 
> Do we really have to nest this test? It seems to gain nothing per se: the annotations and fields are still pretty much duplicated.

Yeah, no. Nesting was to pre-emptively decouple the micros, but it makes sense to squash them into one for now.

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

PR: https://git.openjdk.java.net/jdk/pull/2135

From alanb at openjdk.java.net  Wed Jan 20 15:43:53 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 20 Jan 2021 15:43:53 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v6]
In-Reply-To: <Do5ypkkC4YyQUpwt6XU3IjE1cv2DnfRlx63j3xOVFJ4=.b6d8829c-8974-4448-8db7-1d2d57b9abd3@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <Do5ypkkC4YyQUpwt6XU3IjE1cv2DnfRlx63j3xOVFJ4=.b6d8829c-8974-4448-8db7-1d2d57b9abd3@github.com>
Message-ID: <KVB28eIDcY1cVm1veOgS8EIUNapkhxKZwSx1XotDBgs=.d0ca3308-1f34-4fe8-a258-4aa435f44aa9@github.com>

On Tue, 19 Jan 2021 23:29:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253478: clean up comment in epoll selector

src/java.base/linux/classes/sun/nio/ch/EventFD.java line 60:

> 58:     }
> 59: 
> 60:     static native int eventfd0() throws IOException;

I assume the native methods should be private.

src/java.base/linux/classes/sun/nio/ch/EventFD.java line 41:

> 39:     EventFD() throws IOException {
> 40:         efd = eventfd0();
> 41:         IOUtil.configureBlocking(IOUtil.newFD(efd), false);

If there is just one no-arg constructor then I think it should create the eventfd with the default settings, meaning blocking mode. A second constructor that takes a boolean blocking parameter would be okay too.

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Wed Jan 20 18:03:20 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 20 Jan 2021 18:03:20 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v6]
In-Reply-To: <KVB28eIDcY1cVm1veOgS8EIUNapkhxKZwSx1XotDBgs=.d0ca3308-1f34-4fe8-a258-4aa435f44aa9@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <Do5ypkkC4YyQUpwt6XU3IjE1cv2DnfRlx63j3xOVFJ4=.b6d8829c-8974-4448-8db7-1d2d57b9abd3@github.com>
 <KVB28eIDcY1cVm1veOgS8EIUNapkhxKZwSx1XotDBgs=.d0ca3308-1f34-4fe8-a258-4aa435f44aa9@github.com>
Message-ID: <iuv4Kji3YTuWAESzfRNFvEa0MpQTgvBGlIcnpWA_Aus=.83c3a906-2d09-41b0-8c0c-ca70e2d67dc1@github.com>

On Wed, 20 Jan 2021 15:38:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8253478: clean up comment in epoll selector
>
> src/java.base/linux/classes/sun/nio/ch/EventFD.java line 60:
> 
>> 58:     }
>> 59: 
>> 60:     static native int eventfd0() throws IOException;
> 
> I assume the native methods should be private.

So changed.

> src/java.base/linux/classes/sun/nio/ch/EventFD.java line 41:
> 
>> 39:     EventFD() throws IOException {
>> 40:         efd = eventfd0();
>> 41:         IOUtil.configureBlocking(IOUtil.newFD(efd), false);
> 
> If there is just one no-arg constructor then I think it should create the eventfd with the default settings, meaning blocking mode. A second constructor that takes a boolean blocking parameter would be okay too.

Above suggestions addressed.

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Wed Jan 20 18:03:18 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 20 Jan 2021 18:03:18 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v7]
In-Reply-To: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
Message-ID: <S1q-OIxDuLvNyW8pa_fjJYCDlv_ic19N9Rd_nOMYwcE=.fc02b190-c026-4f37-bb05-d619a5e838ee@github.com>

> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.

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

  8253478: EventFD update: constructors; make native methods private

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2082/files
  - new: https://git.openjdk.java.net/jdk/pull/2082/files/b231c536..cc51c2f8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=05-06

  Stats: 15 lines in 2 files changed: 10 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2082.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2082/head:pull/2082

PR: https://git.openjdk.java.net/jdk/pull/2082

From martinrb at google.com  Wed Jan 20 18:34:17 2021
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Jan 2021 10:34:17 -0800
Subject: JDK-8259873: (fs) Add
 java.nio.file.attribute.BasicWithKeyFileAttributeView interface
In-Reply-To: <8ddd315d-ad8e-7fd6-2189-087266f6569a@oracle.com>
References: <CAFcJ+g6pL_3fUaCAQU+59QcOVSaGc-HrcyBEAW4hjpVvL0OGoQ@mail.gmail.com>
 <CA+kOe09mm9h6M5F2B4v3bzNX6VPE+4xAHQ2Gjs0JFfnsza=b0A@mail.gmail.com>
 <8ddd315d-ad8e-7fd6-2189-087266f6569a@oracle.com>
Message-ID: <CA+kOe0-Q9rHmqMYrnCXcrtGGaLbz=pHE6iqbgpW9gPThdPLgnw@mail.gmail.com>

Hmmmm ...

How about inviting Microsoft folk to review?  They should be experts.

I happen to be very interested in file I/O optimization (but as usual not
enough time!) and was hoping filekeys would help us, but I can see they may
be problematic.

People can and do write their own filesystems, with different performance
objectives.  Looking around at Google I see:

$ stat .
=> Inode: 371    Links: 1  Access: 1969-12-31

That's a suspiciously small inode number for a monorepo.  Other data looks
bogus as well.  A filesystem implementer fills in a stat struct with
whatever is at hand, without a promise of uniqueness for use as a filekey.
For robustness, software that does want uniqueness needs to keep a list of
known reliable filesystem implementations.



On Wed, Jan 20, 2021 at 12:14 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 20/01/2021 07:55, Martin Buchholz wrote:
> > I'm mostly cheerleading here, and haven't developed for Windows in
> > many years, but ... I agree with the strategy here.  More use of file
> > keys would benefit performance on all platforms.  OTOH I worry that
> > filekeys are inconsistently implemented on different OSes and
> filesystems.
> >
> The recent thread with subject line "Files.isSameFile(Path,Path)" may be
> useful to re-read. The JDK has been using the volume serial number and
> file indexes but they are problematic on some volumes (not guarantee to
> be unique, maybe be zero). The Microsoft folks here have been looking to
> replace the usage with the "full path" (the approximate equivalent to
> realpath).
>
> We did a lot work in JDK 7 to make the default case (not following sym
> links) be efficient on Windows. This is the reason for the internal
> BasicFileAttribuetHolder that FileTreeWalker uses to avoid needing to
> read the file attributes. Maybe we could lean on that internal interface
> and try to find options there before adding to the standard API.
>
> Switching from FindFirstFile/FindNextFile to NtQueryDirectoryInformation
> is definitely worth exploring, it will just take significant time to
> review and will likely go through a few review iterations.
>
> -Alan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210120/45355fa6/attachment.htm>

From sebastian.stenzel at gmail.com  Thu Jan 21 05:18:08 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Thu, 21 Jan 2021 06:18:08 +0100
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
Message-ID: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>

Hi all,

since we decided to keep the scope of JDK-8030048 (UserDefinedFileAttributeView for macOS) as small as possible, there is still some potential for cleanup. Most importantly: Remove duplications that I introduced by adding BsdUserDefinedFileAttributeView.

I'm writing this to get discussions on a yet to be defined issue started, that sets the scope of said cleanup. So here is a number of questions and suggestions:

1. Since I'm new to OpenJDK: Is it common to always use the latest language features or should I restrain myself in favour of backports?

2. The main goal is, obviously, deduplication. I.e. a lot of code from the Linux* and Bsd* classes can be moved to their parent: Unix*. We have to keep in mind though, that their sibling Aix* doesn't support UserDefinedAttributeView. Since there are minor differences between BsdNativeDispatcher and LinuxNativeDispatcher, I'd like to know if it's ok to make UnixNativeDispatcher abstract or whether there is a reason why they shouldn't be (any problems with JNI and abstract classes?).

3. NativeBuffer gets used a lot. Is this future proof? Or is it soon to be replaced by the Foreign-Memory Access API? How about using ByteBuffers in conjunction with JNI's GetDirectBufferAddress and GetDirectBufferCapacity instead?

4. If question (1.) can be answered with "yes" and the answer to question (3.) is "stick with NativeBuffer": Can we have NativeBuffer implement AutoCloseable? There are plenty occurrence that would benefit from a try-with-resource statement.

5. Can I somehow convince GitHub Actions to run a specific test case that is not usually included in tier 1 tests? I'm asking because the area that needs rework relies on such a test.

Cheers,
Sebastian

From alanb at openjdk.java.net  Thu Jan 21 10:28:00 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 21 Jan 2021 10:28:00 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v7]
In-Reply-To: <S1q-OIxDuLvNyW8pa_fjJYCDlv_ic19N9Rd_nOMYwcE=.fc02b190-c026-4f37-bb05-d619a5e838ee@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <S1q-OIxDuLvNyW8pa_fjJYCDlv_ic19N9Rd_nOMYwcE=.fc02b190-c026-4f37-bb05-d619a5e838ee@github.com>
Message-ID: <mzPiZP7f9Px5bnjAubnTAPlc4fv2HfpGxvALZ-XSWs8=.fc20640e-54ae-4f28-bbac-fb04763e23e9@github.com>

On Wed, 20 Jan 2021 18:03:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253478: EventFD update: constructors; make native methods private

src/java.base/linux/classes/sun/nio/ch/EventFD.java line 79:

> 77:      * @return the number of bytes written; should equal 8
> 78:      */
> 79:     static private native int set0(int efd) throws IOException;

Minor nit but we usually put the private modifier first.

src/java.base/linux/classes/sun/nio/ch/EventFD.java line 51:

> 49:     EventFD(boolean blocking) throws IOException {
> 50:         efd = eventfd0();
> 51:         IOUtil.configureBlocking(IOUtil.newFD(efd), blocking);

This looks okay but the addition of the blocking parameter means you can go back to one of the early iterations and just calling eventfd with the EFD_NONBLOCK. Up to you.

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From Alan.Bateman at oracle.com  Thu Jan 21 14:08:06 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 21 Jan 2021 14:08:06 +0000
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
Message-ID: <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>

On 21/01/2021 05:18, Sebastian Stenzel wrote:
> Hi all,
>
> since we decided to keep the scope of JDK-8030048 (UserDefinedFileAttributeView for macOS) as small as possible, there is still some potential for cleanup. Most importantly: Remove duplications that I introduced by adding BsdUserDefinedFileAttributeView.
>
> I'm writing this to get discussions on a yet to be defined issue started, that sets the scope of said cleanup. So here is a number of questions and suggestions:
>
> 1. Since I'm new to OpenJDK: Is it common to always use the latest language features or should I restrain myself in favour of backports?
It's okay to use the latest languages features. There are periodically 
limitations, for example it wasn't possible until very recently to use 
the? pattern matching with the instanceof operator due to the bootstrap 
JDK being used to create reference docs. There is a long history where 
it wasn't possible to use newer languages features until very late in a 
release or even the next release.

> 2. The main goal is, obviously, deduplication. I.e. a lot of code from the Linux* and Bsd* classes can be moved to their parent: Unix*. We have to keep in mind though, that their sibling Aix* doesn't support UserDefinedAttributeView. Since there are minor differences between BsdNativeDispatcher and LinuxNativeDispatcher, I'd like to know if it's ok to make UnixNativeDispatcher abstract or whether there is a reason why they shouldn't be (any problems with JNI and abstract classes?).
That would be disruptive change. UnixNativeDispatcher.c already has to 
deal with issues like this and it's okay if the it compiles to 
JNU_ThrowInternalError on AIX. In modules/java.base/Java.gmk you'll seen 
a few examples where specific classes are included/excluded. In this 
case, I assume you will include UnixUserDefinedFileAttributeView in the 
Linux and macOS builds.

>
> 3. NativeBuffer gets used a lot. Is this future proof? Or is it soon to be replaced by the Foreign-Memory Access API? How about using ByteBuffers in conjunction with JNI's GetDirectBufferAddress and GetDirectBufferCapacity instead?
This code uses the internal Unsafe for off-heap memory, it may be that 
further down the road we will replace it with memory segments. I don't 
think this should have any impact on the disucssion here.


> 4. If question (1.) can be answered with "yes" and the answer to question (3.) is "stick with NativeBuffer": Can we have NativeBuffer implement AutoCloseable? There are plenty occurrence that would benefit from a try-with-resource statement.
Yes, this is a good idea.

> 5. Can I somehow convince GitHub Actions to run a specific test case that is not usually included in tier 1 tests? I'm asking because the area that needs rework relies on such a test.
I think there is some configuration needed, maybe someone else can help 
on this.

-Alan.

From rpaquay at google.com  Thu Jan 21 18:20:06 2021
From: rpaquay at google.com (Renaud Paquay)
Date: Thu, 21 Jan 2021 10:20:06 -0800
Subject: JDK-8259873: (fs) Add
 java.nio.file.attribute.BasicWithKeyFileAttributeView interface
In-Reply-To: <CA+kOe0-Q9rHmqMYrnCXcrtGGaLbz=pHE6iqbgpW9gPThdPLgnw@mail.gmail.com>
References: <CAFcJ+g6pL_3fUaCAQU+59QcOVSaGc-HrcyBEAW4hjpVvL0OGoQ@mail.gmail.com>
 <CA+kOe09mm9h6M5F2B4v3bzNX6VPE+4xAHQ2Gjs0JFfnsza=b0A@mail.gmail.com>
 <8ddd315d-ad8e-7fd6-2189-087266f6569a@oracle.com>
 <CA+kOe0-Q9rHmqMYrnCXcrtGGaLbz=pHE6iqbgpW9gPThdPLgnw@mail.gmail.com>
Message-ID: <CAFcJ+g5Gj1khLnTELE9CkQsGsdJcyztTkKhHhQwSmuKpxQzYRg@mail.gmail.com>

>
>> The recent thread with subject line "Files.isSameFile(Path,Path)" may be
>> useful to re-read. The JDK has been using the volume serial number and
>> file indexes but they are problematic on some volumes (not guarantee to
>> be unique, maybe be zero). The Microsoft folks here have been looking to
>> replace the usage with the "full path" (the approximate equivalent to
>> realpath).
>>
>
Reading the isSameFile thread (starting
https://mail.openjdk.java.net/pipermail/nio-dev/2020-October/007682.html),
it looks like the issue is that some file systems (webdav) return all
zeros. The PR we submitted already takes this case in account, and does not
expose a file key if the volume serial is zero (
https://github.com/openjdk/jdk/pull/2122/files#diff-efc9760571de4e32620d825eddb664e654876be4e2fc5f7ef2ead5461adbf7a0R489).
This ensures a bogus file key is never exposed. Of course, this will void
the performance improvements of the CL (avoiding calls to isSameFile on
such file systems), but I believe the behavior is ok, as I doubt we will
find way to make file keys more efficient than using vol serial number and
file indices, and they are available (and reliable) on the vast majority of
windows systems (ntfs file systems). wdyt?


>
>> We did a lot work in JDK 7 to make the default case (not following sym
>> links) be efficient on Windows. This is the reason for the internal
>> BasicFileAttribuetHolder that FileTreeWalker uses to avoid needing to
>> read the file attributes. Maybe we could lean on that internal interface
>> and try to find options there before adding to the standard API.
>>
>
The first change (NtQueryDirectoryFile) does provide
BasicFileAttributeHolder via WindowsDirectoryStream, which is used by
FileTreeWalker (see the acceptEntry method of WindowsDirectoryStream,
https://github.com/openjdk/jdk/pull/2122/files#diff-447e8d9c0cfa24aa5bc1d30cbfa0843cca93366c79d0e7bfa377c14b656f39c6L147
).

The remaining problem is that FileTreeWalker does *not* have a
BasicFileAttributeHolder for the initial directory, hence does not have a
file key, hence requires calling the slower isSameFile methods. I am open
to suggestions on how to provide a file key for the initial directory other
than exposing a new interface, but afaik, BasicFileAttributeHolder is not
involved in this special case of the initial directory. Essentially, we
need a way for FileTreeWalker to say "I would like attributes including a
file key if possible, even if it means using a slower implementation".


>
>> Switching from FindFirstFile/FindNextFile to NtQueryDirectoryInformation
>> is definitely worth exploring, it will just take significant time to
>> review and will likely go through a few review iterations.
>>
>
Ok, I am not sure I fully understand what this means. We are of course open
to making tweaks to the CL as needed, but do you need anything from us to
move forward at this point? For example, we have a small benchmark app if
needed. Also, for context, we applied these changes to Android Studio about
1.5 year ago (openjdk 8 and 11), and we have not seen issues. (Android
Studio has hundreds of thousands of active Windows users)


>
> How about inviting Microsoft folk to review?  They should be experts.
>

That would be great :)

Thanks,
Renaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210121/dfead69d/attachment.htm>

From bpb at openjdk.java.net  Thu Jan 21 19:34:33 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 21 Jan 2021 19:34:33 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v7]
In-Reply-To: <mzPiZP7f9Px5bnjAubnTAPlc4fv2HfpGxvALZ-XSWs8=.fc20640e-54ae-4f28-bbac-fb04763e23e9@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <S1q-OIxDuLvNyW8pa_fjJYCDlv_ic19N9Rd_nOMYwcE=.fc02b190-c026-4f37-bb05-d619a5e838ee@github.com>
 <mzPiZP7f9Px5bnjAubnTAPlc4fv2HfpGxvALZ-XSWs8=.fc20640e-54ae-4f28-bbac-fb04763e23e9@github.com>
Message-ID: <QOiuOpqORLjenEpZOWgzESxMWJ11BpPHqg-WwrdeiYU=.5ceebbb9-9011-4279-b950-bc6cf95befb0@github.com>

On Thu, 21 Jan 2021 10:24:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8253478: EventFD update: constructors; make native methods private
>
> src/java.base/linux/classes/sun/nio/ch/EventFD.java line 51:
> 
>> 49:     EventFD(boolean blocking) throws IOException {
>> 50:         efd = eventfd0();
>> 51:         IOUtil.configureBlocking(IOUtil.newFD(efd), blocking);
> 
> This looks okay but the addition of the blocking parameter means you can go back to one of the early iterations and just calling eventfd with the EFD_NONBLOCK. Up to you.

I am not sure I understand this comment as a previous comment preferred `IOUtil.configureBlocking()` to set the blocking state.

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From alanb at openjdk.java.net  Thu Jan 21 19:42:53 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 21 Jan 2021 19:42:53 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v7]
In-Reply-To: <QOiuOpqORLjenEpZOWgzESxMWJ11BpPHqg-WwrdeiYU=.5ceebbb9-9011-4279-b950-bc6cf95befb0@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <S1q-OIxDuLvNyW8pa_fjJYCDlv_ic19N9Rd_nOMYwcE=.fc02b190-c026-4f37-bb05-d619a5e838ee@github.com>
 <mzPiZP7f9Px5bnjAubnTAPlc4fv2HfpGxvALZ-XSWs8=.fc20640e-54ae-4f28-bbac-fb04763e23e9@github.com>
 <QOiuOpqORLjenEpZOWgzESxMWJ11BpPHqg-WwrdeiYU=.5ceebbb9-9011-4279-b950-bc6cf95befb0@github.com>
Message-ID: <bKywYkbLdNSj4TPzCp4vomar8D3A1QCDqWs5z38eKHQ=.d7b6291e-c703-40fc-b336-8003246b0939@github.com>

On Thu, 21 Jan 2021 19:30:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/linux/classes/sun/nio/ch/EventFD.java line 51:
>> 
>>> 49:     EventFD(boolean blocking) throws IOException {
>>> 50:         efd = eventfd0();
>>> 51:         IOUtil.configureBlocking(IOUtil.newFD(efd), blocking);
>> 
>> This looks okay but the addition of the blocking parameter means you can go back to one of the early iterations and just calling eventfd with the EFD_NONBLOCK. Up to you.
>
> I am not sure I understand this comment as a previous comment preferred `IOUtil.configureBlocking()` to set the blocking state.

The previous comments were in the context of the no-arg EventFD constructor where we expected it would be created in blocking mode. In that context EPollSelectorImpl would use IOUtil.configureBlocking to configure it to non-blocking. In the new version, there is a blocking parameter so EventFD can use IOUtil.configureBlocking when blocking is "false", or specify EFD_NONBLOCK to eventfd, either is okay with me.

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From alanb at openjdk.java.net  Thu Jan 21 20:03:24 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 21 Jan 2021 20:03:24 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v8]
In-Reply-To: <YXC85cMxVpxpxNAmwI3pAsT3TZOhjnUujTivX9aieP4=.b5114306-2102-4ed5-bfd9-088686423fe0@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
 <YXC85cMxVpxpxNAmwI3pAsT3TZOhjnUujTivX9aieP4=.b5114306-2102-4ed5-bfd9-088686423fe0@github.com>
Message-ID: <d0DLkzOXRUnoaHQOeak9cN_PL37vhY-l_RrZcrNKAPI=.0d12cdf6-e580-4d0a-a750-16d423eea290@github.com>

On Thu, 21 Jan 2021 19:54:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253478: Remove one-arg constructor; clean up native declarations

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Thu Jan 21 20:03:21 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 21 Jan 2021 20:03:21 GMT
Subject: RFR: 8253478: (se) epoll Selector should use eventfd for wakeup
 instead of pipe [v8]
In-Reply-To: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
Message-ID: <YXC85cMxVpxpxNAmwI3pAsT3TZOhjnUujTivX9aieP4=.b5114306-2102-4ed5-bfd9-088686423fe0@github.com>

> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.

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

  8253478: Remove one-arg constructor; clean up native declarations

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2082/files
  - new: https://git.openjdk.java.net/jdk/pull/2082/files/cc51c2f8..040da3b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2082&range=06-07

  Stats: 15 lines in 2 files changed: 1 ins; 11 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2082.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2082/head:pull/2082

PR: https://git.openjdk.java.net/jdk/pull/2082

From bpb at openjdk.java.net  Thu Jan 21 21:42:23 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 21 Jan 2021 21:42:23 GMT
Subject: Integrated: 8253478: (se) epoll Selector should use eventfd for
 wakeup instead of pipe
In-Reply-To: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
References: <Er9V2qnUPzfNJkmkDcSLwdYAK6goXR0zCssfzgB6fPQ=.d36868f7-1776-4a67-95d7-93e8a427997b@github.com>
Message-ID: <Sb934vigPuI0z60BuJX-weL2p_vlT3o_KjK6rKTP0do=.c9d95ac6-3467-4230-9267-8bc1caafbeea@github.com>

On Thu, 14 Jan 2021 16:44:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this change which modifies the Linux `epoll(7)`-based `Selector` to use `eventfd(2)` instead of `pipe(2)` in its wakeup mechanism. The change passes all tier 1-tier 3 tests on Linux. Based on rudimentary testing, there does not appear to be any appreciable change in performance. One improvement however is that only one file descriptor instead of two is used for the wakeup. No test is included as the code is covered well by existing tests.

This pull request has now been integrated.

Changeset: a8073efe
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a8073efe
Stats:     203 lines in 4 files changed: 189 ins; 3 del; 11 mod

8253478: (se) epoll Selector should use eventfd for wakeup instead of pipe

Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk/pull/2082

From Alan.Bateman at oracle.com  Fri Jan 22 15:56:08 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 22 Jan 2021 15:56:08 +0000
Subject: JDK-8259873: (fs) Add
 java.nio.file.attribute.BasicWithKeyFileAttributeView interface
In-Reply-To: <CAFcJ+g5Gj1khLnTELE9CkQsGsdJcyztTkKhHhQwSmuKpxQzYRg@mail.gmail.com>
References: <CAFcJ+g6pL_3fUaCAQU+59QcOVSaGc-HrcyBEAW4hjpVvL0OGoQ@mail.gmail.com>
 <CA+kOe09mm9h6M5F2B4v3bzNX6VPE+4xAHQ2Gjs0JFfnsza=b0A@mail.gmail.com>
 <8ddd315d-ad8e-7fd6-2189-087266f6569a@oracle.com>
 <CA+kOe0-Q9rHmqMYrnCXcrtGGaLbz=pHE6iqbgpW9gPThdPLgnw@mail.gmail.com>
 <CAFcJ+g5Gj1khLnTELE9CkQsGsdJcyztTkKhHhQwSmuKpxQzYRg@mail.gmail.com>
Message-ID: <9ce9abfe-7251-8a36-3259-732715cee584@oracle.com>

On 21/01/2021 18:20, Renaud Paquay wrote:
> :
>
>
>         Switching from FindFirstFile/FindNextFile to
>         NtQueryDirectoryInformation
>         is definitely worth exploring, it will just take significant
>         time to
>         review and will likely go through a few review iterations.
>
>
> Ok, I am not sure I fully understand what this means. We are of course 
> open to making tweaks to the CL as needed, but do you need anything 
> from us to move forward at this point? For example, we have a small 
> benchmark app if needed.
I plan to review the changes. NtQueryDirectoryInformation is kernel 
function so at a lower level that we've been using to date. I'm sure 
there will be at least a few iterations. I'm more concerned about the 
proposal to add to the standard API, I suspect that one will require 
more exploratory.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210122/8137a190/attachment.htm>

From shade at openjdk.java.net  Fri Jan 22 17:00:54 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 22 Jan 2021 17:00:54 GMT
Subject: RFR: 8260304: (se) EPollSelectorImpl wakeup mechanism broken on Linux
 32-bit
Message-ID: <jCzksmx_FBfFGpDXvYnwcuwzrscw3ecfkEf_EtR9vyw=.47bdc46f-43ff-4c3b-bdd9-cc0adeee7477@github.com>

This readily manifests in GH Actions testing, for example:
 https://github.com/shipilev/jdk/runs/1748754939

Reproducible locally with:

$ CONF=linux-x86-server-fastdebug make images run-test TEST=sun/misc/JarIndex/metaInfFilenames/Basic.java
...
Caused by: java.io.IOException: Invalid argument
at java.base/sun.nio.ch.EventFD.set0(Native Method)
at java.base/sun.nio.ch.EventFD.set(EventFD.java:48)
at java.base/sun.nio.ch.EPollSelectorImpl.wakeup(EPollSelectorImpl.java:251)

The failure is obvious when you look at the code: `long` should be `uint64_t`.

Additional testing:
 - [x] Failing test on Linux x86_32 (now passes)
 - [x] Failing test on Linux x86_64 (still passes)

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

Commit messages:
 - 8260304: (se) EPollSelectorImpl wakeup mechanism broken on Linux 32-bit

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

PR: https://git.openjdk.java.net/jdk/pull/2196

From shade at openjdk.java.net  Fri Jan 22 17:10:01 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 22 Jan 2021 17:10:01 GMT
Subject: RFR: 8260304: (se) EPollSelectorImpl wakeup mechanism broken on
 Linux 32-bit [v2]
In-Reply-To: <jCzksmx_FBfFGpDXvYnwcuwzrscw3ecfkEf_EtR9vyw=.47bdc46f-43ff-4c3b-bdd9-cc0adeee7477@github.com>
References: <jCzksmx_FBfFGpDXvYnwcuwzrscw3ecfkEf_EtR9vyw=.47bdc46f-43ff-4c3b-bdd9-cc0adeee7477@github.com>
Message-ID: <Ba-gIaKW2d5cbnDDVcGlX4QPyiy73nzrsT3RLWurZyQ=.09198684-0879-41d4-8e73-7de58d727a9b@github.com>

> This readily manifests in GH Actions testing, for example:
>  https://github.com/shipilev/jdk/runs/1748754939
> 
> Reproducible locally with:
> 
> $ CONF=linux-x86-server-fastdebug make images run-test TEST=sun/misc/JarIndex/metaInfFilenames/Basic.java
> ...
> Caused by: java.io.IOException: Invalid argument
> at java.base/sun.nio.ch.EventFD.set0(Native Method)
> at java.base/sun.nio.ch.EventFD.set(EventFD.java:48)
> at java.base/sun.nio.ch.EPollSelectorImpl.wakeup(EPollSelectorImpl.java:251)
> 
> The failure is obvious when you look at the code: `long` should be `uint64_t`.
> 
> Additional testing:
>  - [x] Failing test on Linux x86_32 (now passes)
>  - [x] Failing test on Linux x86_64 (still passes)

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

  Use the proper suffix for uint64_t literal, while we are at it

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2196/files
  - new: https://git.openjdk.java.net/jdk/pull/2196/files/51f324ae..feeb3320

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2196&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2196&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2196

From bpb at openjdk.java.net  Fri Jan 22 17:10:02 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 22 Jan 2021 17:10:02 GMT
Subject: RFR: 8260304: (se) EPollSelectorImpl wakeup mechanism broken on
 Linux 32-bit [v2]
In-Reply-To: <Ba-gIaKW2d5cbnDDVcGlX4QPyiy73nzrsT3RLWurZyQ=.09198684-0879-41d4-8e73-7de58d727a9b@github.com>
References: <jCzksmx_FBfFGpDXvYnwcuwzrscw3ecfkEf_EtR9vyw=.47bdc46f-43ff-4c3b-bdd9-cc0adeee7477@github.com>
 <Ba-gIaKW2d5cbnDDVcGlX4QPyiy73nzrsT3RLWurZyQ=.09198684-0879-41d4-8e73-7de58d727a9b@github.com>
Message-ID: <KGffgmFByuQ8A9MXsZAtmvH7nheB3YQQ9ZTHk2q5z_I=.1ea18be4-239b-4165-abd7-b8427ae4394c@github.com>

On Fri, 22 Jan 2021 17:06:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This readily manifests in GH Actions testing, for example:
>>  https://github.com/shipilev/jdk/runs/1748754939
>> 
>> Reproducible locally with:
>> 
>> $ CONF=linux-x86-server-fastdebug make images run-test TEST=sun/misc/JarIndex/metaInfFilenames/Basic.java
>> ...
>> Caused by: java.io.IOException: Invalid argument
>> at java.base/sun.nio.ch.EventFD.set0(Native Method)
>> at java.base/sun.nio.ch.EventFD.set(EventFD.java:48)
>> at java.base/sun.nio.ch.EPollSelectorImpl.wakeup(EPollSelectorImpl.java:251)
>> 
>> The failure is obvious when you look at the code: `long` should be `uint64_t`.
>> 
>> Additional testing:
>>  - [x] Failing test on Linux x86_32 (now passes)
>>  - [x] Failing test on Linux x86_64 (still passes)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the proper suffix for uint64_t literal, while we are at it

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2196

From alanb at openjdk.java.net  Fri Jan 22 17:10:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 22 Jan 2021 17:10:03 GMT
Subject: RFR: 8260304: (se) EPollSelectorImpl wakeup mechanism broken on
 Linux 32-bit [v2]
In-Reply-To: <Ba-gIaKW2d5cbnDDVcGlX4QPyiy73nzrsT3RLWurZyQ=.09198684-0879-41d4-8e73-7de58d727a9b@github.com>
References: <jCzksmx_FBfFGpDXvYnwcuwzrscw3ecfkEf_EtR9vyw=.47bdc46f-43ff-4c3b-bdd9-cc0adeee7477@github.com>
 <Ba-gIaKW2d5cbnDDVcGlX4QPyiy73nzrsT3RLWurZyQ=.09198684-0879-41d4-8e73-7de58d727a9b@github.com>
Message-ID: <X-T3X6Pbk59E1ZY7BW33Y8iHz4ymZO1H37Aa0aGnFsM=.35a302c0-6072-49e2-a9aa-e47aca85c695@github.com>

On Fri, 22 Jan 2021 17:06:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This readily manifests in GH Actions testing, for example:
>>  https://github.com/shipilev/jdk/runs/1748754939
>> 
>> Reproducible locally with:
>> 
>> $ CONF=linux-x86-server-fastdebug make images run-test TEST=sun/misc/JarIndex/metaInfFilenames/Basic.java
>> ...
>> Caused by: java.io.IOException: Invalid argument
>> at java.base/sun.nio.ch.EventFD.set0(Native Method)
>> at java.base/sun.nio.ch.EventFD.set(EventFD.java:48)
>> at java.base/sun.nio.ch.EPollSelectorImpl.wakeup(EPollSelectorImpl.java:251)
>> 
>> The failure is obvious when you look at the code: `long` should be `uint64_t`.
>> 
>> Additional testing:
>>  - [x] Failing test on Linux x86_32 (now passes)
>>  - [x] Failing test on Linux x86_64 (still passes)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the proper suffix for uint64_t literal, while we are at it

Yeah, should be uint64_t as the write to eventfd must be 8 bytes.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2196

From shade at openjdk.java.net  Fri Jan 22 17:10:03 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 22 Jan 2021 17:10:03 GMT
Subject: RFR: 8260304: (se) EPollSelectorImpl wakeup mechanism broken on
 Linux 32-bit [v2]
In-Reply-To: <X-T3X6Pbk59E1ZY7BW33Y8iHz4ymZO1H37Aa0aGnFsM=.35a302c0-6072-49e2-a9aa-e47aca85c695@github.com>
References: <jCzksmx_FBfFGpDXvYnwcuwzrscw3ecfkEf_EtR9vyw=.47bdc46f-43ff-4c3b-bdd9-cc0adeee7477@github.com>
 <Ba-gIaKW2d5cbnDDVcGlX4QPyiy73nzrsT3RLWurZyQ=.09198684-0879-41d4-8e73-7de58d727a9b@github.com>
 <X-T3X6Pbk59E1ZY7BW33Y8iHz4ymZO1H37Aa0aGnFsM=.35a302c0-6072-49e2-a9aa-e47aca85c695@github.com>
Message-ID: <2ODfvpdBrm4J7r48_9nPajqJ6rQBy--wJlHZGBC8xZY=.83bc74ef-8874-4ca9-a86c-93d180e288f4@github.com>

On Fri, 22 Jan 2021 17:03:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use the proper suffix for uint64_t literal, while we are at it
>
> Yeah, should be uint64_t as the write to eventfd must be 8 bytes.

Self-bikeshedded myself: let's do `ULL` suffix, while we are at it. See update.

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

PR: https://git.openjdk.java.net/jdk/pull/2196

From shade at openjdk.java.net  Fri Jan 22 20:01:41 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 22 Jan 2021 20:01:41 GMT
Subject: Integrated: 8260304: (se) EPollSelectorImpl wakeup mechanism broken
 on Linux 32-bit
In-Reply-To: <jCzksmx_FBfFGpDXvYnwcuwzrscw3ecfkEf_EtR9vyw=.47bdc46f-43ff-4c3b-bdd9-cc0adeee7477@github.com>
References: <jCzksmx_FBfFGpDXvYnwcuwzrscw3ecfkEf_EtR9vyw=.47bdc46f-43ff-4c3b-bdd9-cc0adeee7477@github.com>
Message-ID: <ou8ajMMnMtp1sxDi_D89Uv6ApMWUl1XxXX-z-AGNwbE=.31af0512-53c6-40e6-9b0f-c25e672e2c7f@github.com>

On Fri, 22 Jan 2021 16:56:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This readily manifests in GH Actions testing, for example:
>  https://github.com/shipilev/jdk/runs/1748754939
> 
> Reproducible locally with:
> 
> $ CONF=linux-x86-server-fastdebug make images run-test TEST=sun/misc/JarIndex/metaInfFilenames/Basic.java
> ...
> Caused by: java.io.IOException: Invalid argument
> at java.base/sun.nio.ch.EventFD.set0(Native Method)
> at java.base/sun.nio.ch.EventFD.set(EventFD.java:48)
> at java.base/sun.nio.ch.EPollSelectorImpl.wakeup(EPollSelectorImpl.java:251)
> 
> The failure is obvious when you look at the code: `long` should be `uint64_t`.
> 
> Additional testing:
>  - [x] Failing test on Linux x86_32 (now passes)
>  - [x] Failing test on Linux x86_64 (still passes)

This pull request has now been integrated.

Changeset: 5aca934c
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5aca934c
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8260304: (se) EPollSelectorImpl wakeup mechanism broken on Linux 32-bit

Reviewed-by: bpb, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/2196

From sebastian.stenzel at gmail.com  Mon Jan 25 08:30:41 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Mon, 25 Jan 2021 09:30:41 +0100
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
Message-ID: <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>


> On 21. Jan 2021, at 15:08, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>> 2. The main goal is, obviously, deduplication. I.e. a lot of code from the Linux* and Bsd* classes can be moved to their parent: Unix*. We have to keep in mind though, that their sibling Aix* doesn't support UserDefinedAttributeView. Since there are minor differences between BsdNativeDispatcher and LinuxNativeDispatcher, I'd like to know if it's ok to make UnixNativeDispatcher abstract or whether there is a reason why they shouldn't be (any problems with JNI and abstract classes?).
> That would be disruptive change. UnixNativeDispatcher.c already has to deal with issues like this and it's okay if the it compiles to JNU_ThrowInternalError on AIX. In modules/java.base/Java.gmk you'll seen a few examples where specific classes are included/excluded. In this case, I assume you will include UnixUserDefinedFileAttributeView in the Linux and macOS builds.

I have to admit, that I don't feel too comfortable with branching code based on preprocessor directives, therefore I preferred to keep native code OS specific. But let's give it a try:

I guess the pattern here is to assign the `my_methodhandle` to whatever applies during init(), as it is done e.g. for `my_futimens_func`? May I ask why this is done via dlsym()? Since the code is inside an #ifdef directive, so the compiler can't reach it if not applicable, can't I just assign my_futimens_func = futimens?

Am I right that we're dealing with four platforms (Linux, Aix, BSD and macOS, the latter being a "special" BSD), that can be distinguished via #ifdef using one of these:

```
__linux__
_AIX
_ALLBSD_SOURCE
MACOSX
```

What about `#ifdef __APPLE__`? I can see this used in various other places.

If `_ALLBSD_SOURCE` is supposed to include all BSD flavours, can I simplify this:

```
#if defined(__linux__) || defined(_AIX)
#include <string.h>
#endif

#ifdef _ALLBSD_SOURCE
#include <string.h>
...
#endif
```

to this:

```
#include <string.h>
```

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210125/6debbc6a/attachment.htm>

From Alan.Bateman at oracle.com  Mon Jan 25 14:00:06 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 25 Jan 2021 14:00:06 +0000
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
 <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
Message-ID: <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>

On 25/01/2021 08:30, Sebastian Stenzel wrote:
>
> I guess the pattern here is to assign the `my_methodhandle` to 
> whatever applies during init(), as it is done e.g. for 
> `my_futimens_func`? May I ask why this is done via dlsym()? Since the 
> code is inside an #ifdef directive, so the compiler can't reach it if 
> not applicable, can't I just assign my_futimens_func = futimens?
>
> Am I right that we're dealing with four platforms (Linux, Aix, BSD and 
> macOS, the latter being a "special" BSD), that can be distinguished 
> via #ifdef using one of these:
>
> ```
> __linux__
> _AIX
> _ALLBSD_SOURCE
> MACOSX
> ```
>
> What about `#ifdef?__APPLE__`? I can see this used in various other 
> places.
>
> If `_ALLBSD_SOURCE` is supposed to include all BSD flavours, can I 
> simplify this:
>
> ```
> #if?defined(__linux__) || defined(_AIX)
> #include?<string.h>
> #endif
>
> #ifdef?_ALLBSD_SOURCE
> #include?<string.h>
> ...
> #endif
> ```
>
> to this:
>
> ```
> #include <string.h>
> ```
>
> ?

The xxx_func setup in the LinuxNativeDispatcher_init date when from when 
the xattr functions weren't in the include files used at build-time. A 
potential first step is to include <attr/xattr.h> and get that change 
bedded in.

The _ALLBSD_SOURCE vs. MACOSX vs. ... is unfortunate and stems from how 
the macOS port came into JDK 7u4. No objection to use _ALLBSD_SOURCE.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210125/76a19e5e/attachment.htm>

From bpb at openjdk.java.net  Tue Jan 26 00:43:51 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 26 Jan 2021 00:43:51 GMT
Subject: RFR: 8129776: The optimized Stream returned from Files.lines should
 unmap the mapped byte buffer (if created) when closed
Message-ID: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>

Please review this proposed change to unmap the mapped buffer shared between the root and sub-spliterators used in the optimized `Stream` implementation returned by `Files.lines()`. A reference counter is added to track the total number of spliterators sharing the buffer. It is set to 1 when the shared buffer is created, and incremented each time a sub-spliterator is created. It is decremented when traversing begins or when the spliterator is closed. If the counter is zero after it is decremented then the shared buffer is unmapped.

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

Commit messages:
 - 8129776: The optimized Stream returned from Files.lines should unmap the mapped byte buffer (if created) when closed

Changes: https://git.openjdk.java.net/jdk/pull/2229/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2229&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8129776
  Stats: 54 lines in 2 files changed: 38 ins; 8 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2229.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2229/head:pull/2229

PR: https://git.openjdk.java.net/jdk/pull/2229

From rriggs at openjdk.java.net  Tue Jan 26 15:19:43 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 26 Jan 2021 15:19:43 GMT
Subject: RFR: 8129776: The optimized Stream returned from Files.lines
 should unmap the mapped byte buffer (if created) when closed
In-Reply-To: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
References: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
Message-ID: <cjBR8FQj3VNSJnwGTT0GNigNv6Hg5NZWKW1Uy3vA6Ik=.ac6ce50e-9d80-4a82-9252-c55e66da113a@github.com>

On Mon, 25 Jan 2021 23:55:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this proposed change to unmap the mapped buffer shared between the root and sub-spliterators used in the optimized `Stream` implementation returned by `Files.lines()`. A reference counter is added to track the total number of spliterators sharing the buffer. It is set to 1 when the shared buffer is created, and incremented each time a sub-spliterator is created. It is decremented when traversing begins or when the spliterator is closed. If the counter is zero after it is decremented then the shared buffer is unmapped.

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/nio/file/Files.java line 4128:

> 4126:                 return StreamSupport.stream(fcls, false)
> 4127:                         .onClose(Files.asUncheckedRunnable(fc))
> 4128:                         .onClose(() -> { fcls.close(); });

Typically, the brackets {} are omitted for a single expression.

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

PR: https://git.openjdk.java.net/jdk/pull/2229

From chegar at openjdk.java.net  Tue Jan 26 16:53:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 26 Jan 2021 16:53:42 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]
In-Reply-To: <5aRQdVf_tbxSwfbsvWMcqO_kBNTZ2m5RuZ6djoqGWQk=.a7c618fe-096f-43f9-b897-ba9ad4fd3dce@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
 <errcLY0kIB3FnhDO18G3aH0YepgWutAIheDPTkrvPfg=.4fe346ab-5eba-4230-9765-be1095f9f844@github.com>
 <4QlCNtToXuqjt-0lnwZgVwjkEr04wWmh_AYvQLOq2BA=.38b61f48-c633-488a-a9b0-8137346013c5@github.com>
 <nkpF544xQjSTdHoDwDQjxYrFJ_CZTk0KuKJzOAS12og=.98bad397-790c-4c81-991f-31fed28ae512@github.com>
 <5aRQdVf_tbxSwfbsvWMcqO_kBNTZ2m5RuZ6djoqGWQk=.a7c618fe-096f-43f9-b897-ba9ad4fd3dce@github.com>
Message-ID: <Aq3KUVDHGqw4Nmyqnl9sKm3akJ9F6SUq_h3v0ApfNIY=.3a1eb056-db2d-4320-9798-1bb7871ea81b@github.com>

On Thu, 10 Dec 2020 14:01:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> While the updated set of scenarios covered by this benchmark is
>> reasonably (and vastly improves coverage), I find myself reluctant to
>> add the last remaining buffer property - read-only views. It's time to
>> template the generation of this code!
>
> If the cases get to be too many, you might also want to consider splitting the benchmark class into several classes that cover different cases (we did this for the memory access benchmarks as well). That would also make it easier to run a subset of cases in isolation.

All comments to date have been addressed. Unless there are any further comments, I would like to integrate this change.

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

PR: https://git.openjdk.java.net/jdk/pull/1430

From bpb at openjdk.java.net  Tue Jan 26 17:12:58 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 26 Jan 2021 17:12:58 GMT
Subject: RFR: 8129776: The optimized Stream returned from Files.lines
 should unmap the mapped byte buffer (if created) when closed [v2]
In-Reply-To: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
References: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
Message-ID: <5_DYk4CoO8OGWtlmjls0cnyhN6wWghXZ3_C6pZUt8xw=.bbb515ca-e5a5-4cc9-8ff7-2807aabb796a@github.com>

> Please review this proposed change to unmap the mapped buffer shared between the root and sub-spliterators used in the optimized `Stream` implementation returned by `Files.lines()`. A reference counter is added to track the total number of spliterators sharing the buffer. It is set to 1 when the shared buffer is created, and incremented each time a sub-spliterator is created. It is decremented when traversing begins or when the spliterator is closed. If the counter is zero after it is decremented then the shared buffer is unmapped.

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

  8129776: Remove brackets {} around single expression lambda

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2229/files
  - new: https://git.openjdk.java.net/jdk/pull/2229/files/37821410..36c34a5d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2229&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2229&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2229

From chegar at openjdk.java.net  Tue Jan 26 17:22:13 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 26 Jan 2021 17:22:13 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v6]
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <AulnwYAjRQigEj5nTE4SrjLpyax2fjL9Hth2UnPP9SI=.6a5b04b4-569c-482d-87e5-df4e21c379f2@github.com>

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

Chris Hegarty 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 ten additional commits since the last revision:

 - Update copyright year range and tailing whitespace
 - Merge branch 'master' into bb-bench
 - Template generation of carrier specific micro-benchmarks.
   
   * Benchmarks are now split out into carrier specific source files
   * All variants and views are covered
   * Test scenario naming is idiomatic
   
   Even with the split by carrier, regex expressions can be used to easily run subsets the benchmarks. E.g. test all memory operations related to Short with read-only buffers:
   
   $ java -jar benchmarks.jar "org.openjdk.bench.java.nio..*Buffers.testDirect.*Short.*"  -l
   Benchmarks:
   org.openjdk.bench.java.nio.ByteBuffers.testDirectLoopGetShortRO
   org.openjdk.bench.java.nio.ByteBuffers.testDirectLoopGetShortSwapRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectBulkGetShortViewRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectBulkGetShortViewSwapRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectLoopGetShortViewRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectLoopGetShortViewSwapRO
 - Merge branch 'master' into bb-bench
 - Add explicitly allocated heap carrier buffer tests
 - Replace Single with Loop
 - whitespace
 - Add additional carrier views and endianness variants.
   
   A large number of variants are now covered. The individual benchmarks conform to the following convention:
     test(Direct|Heap)(Bulk|Single)(Get|Put)(Byte|Char|Short|Int|Long|Float|Double)(View)?(Swap)?
   
   This allows to easily run a subset of particular interest. For example:
     Direct only :- "org.openjdk.bench.java.nio.ByteBuffers.testDirect.*"
     Char only   :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Char.*"
     Bulk only   :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Bulk.*"
     Put with Int or Long carrier :-
        test(Direct|Heap)(Single)(Put)(Int|Long)(View)?(Swap)?"
   
   Running all variants together is likely not all that useful, since there will be a lot of data.
   
   The param sizes are changed so as to better allow for wider carrier views.
   
   There are a lot of individual benchmark methods, but their implementation is trivial, and largely mechanical.
   
   Question: where do folk stand on having a `main` method in a benchmark - as a standalone-run sanity? I found this useful to assert the validity of the benchmark code. It can be commented out if it could somehow affect the benchmark runs.
   
   ( I omitted read-only views, since they less interesting, and we already have a lot of variants )
 - Initial changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1430/files
  - new: https://git.openjdk.java.net/jdk/pull/1430/files/a8e81a84..9e8014cf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=04-05

  Stats: 123643 lines in 3239 files changed: 61246 ins; 39707 del; 22690 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1430.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1430/head:pull/1430

PR: https://git.openjdk.java.net/jdk/pull/1430

From github.com+471021+marschall at openjdk.java.net  Tue Jan 26 18:22:02 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 26 Jan 2021 18:22:02 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]
In-Reply-To: <TujK1flvtJ144KxV3OE5JgwAbQ6X4GRS8EWuskcE_A0=.786a8094-0066-4012-abfb-dc0f97b0f9f8@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <E8UILDsjWetV8n_CS6BsLUpAS9YNOyFup_zlV0uXaNY=.7df5871c-da6d-41e8-a0a5-c39503e50297@github.com>
 <66uDvXvRZ0UyNV93dFYWuQ-xp7GM-eVjCxsP-Aa0fMY=.46a98be7-25d9-4091-8db2-5b25beb5a9b1@github.com>
 <TujK1flvtJ144KxV3OE5JgwAbQ6X4GRS8EWuskcE_A0=.786a8094-0066-4012-abfb-dc0f97b0f9f8@github.com>
Message-ID: <T_ipXFaf3d4GIT0HxS-oSKdss9Yensfqd8qt6uQ8_So=.8e915e8e-0297-46fb-96f8-beab5439159a@github.com>

On Tue, 19 Jan 2021 07:22:49 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 207:
>> 
>>> 205:                         target.put(cbuf, 0, n);
>>> 206:                         nread += n;
>>> 207:                         remaining -= n;
>> 
>> Wouldn't there be a possibility for target.put(cbuf, 0, n) to throw BufferOverflowException ?
>> For example:
>> - there's room (remaining) for TRANSFER_BUFFER_SIZE + 1 characters in target
>> - cbuff is sized to TRANSFER_BUFFER_SIZE
>> - 1st iteration of do loop transfers TRANSFER_BUFFER_SIZE charasters (remaining == 1)
>> - 2nd iteration reads > 1 (up to TRANSFER_BUFFER_SIZE) characters
>> - target.put throws BufferOverflowException
>> 
>> You have to limit the amount read in each iteration to be Math.min(remaining, cbuf.length)
>
> You're correct. I need to expand the unit tests.

Fixed

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From github.com+471021+marschall at openjdk.java.net  Tue Jan 26 18:22:02 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 26 Jan 2021 18:22:02 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v5]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <0iyhKVh5Aq4_7Smt9_-gBboOoEC0tGl5iv_QNzJLhYc=.c4145fe6-ebcc-4ac2-a623-692061f02229@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

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

  Limit amount read to avoid BufferOverflowException
  
  - limit the amount read
  - add tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/d247b637..a8531c1b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=03-04

  Stats: 79 lines in 2 files changed: 62 ins; 2 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915

PR: https://git.openjdk.java.net/jdk/pull/1915

From psandoz at openjdk.java.net  Tue Jan 26 19:56:40 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 26 Jan 2021 19:56:40 GMT
Subject: RFR: 8129776: The optimized Stream returned from Files.lines
 should unmap the mapped byte buffer (if created) when closed [v2]
In-Reply-To: <cjBR8FQj3VNSJnwGTT0GNigNv6Hg5NZWKW1Uy3vA6Ik=.ac6ce50e-9d80-4a82-9252-c55e66da113a@github.com>
References: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
 <cjBR8FQj3VNSJnwGTT0GNigNv6Hg5NZWKW1Uy3vA6Ik=.ac6ce50e-9d80-4a82-9252-c55e66da113a@github.com>
Message-ID: <nAI4603Kr1RdBu_pXheZ75wkSMNyoacbGkfIOpYpcM4=.bf88497c-b92e-472d-a327-3a3c03fcbe6f@github.com>

On Tue, 26 Jan 2021 15:16:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8129776: Remove brackets {} around single expression lambda
>
> Marked as reviewed by rriggs (Reviewer).

Looks good. There is some complexity because the `Spliterator` can be obtained from the `Stream` returned by `Files.lines()`. This is not a common case but unfortunately we need to deal with it, otherwise we could just unmap when the `Stream` is closed.  There are edge cases where by splits may occur but they are not traversed, but i don't think we should be concerned about. This is on a good best-effort basis to free up the resource.

Is unmapping via `nioAccess.unmapper(b).unmap();` wired up?

In `Buffer`:
                @Override
                public UnmapperProxy unmapper(ByteBuffer bb) {
                    if (bb instanceof MappedByteBuffer) {
                        return ((MappedByteBuffer)bb).unmapper();
                    } else {
                        return null;
                    }
                }

In MappedByteBuffer:
    UnmapperProxy unmapper() {
        return fd != null ?
                new UnmapperProxy() {
                    @Override
                    public long address() {
                        return address;
                    }

                    @Override
                    public FileDescriptor fileDescriptor() {
                        return fd;
                    }

                    @Override
                    public boolean isSync() {
                        return isSync;
                    }

                    @Override
                    public void unmap() {
                        throw new UnsupportedOperationException();
                    }
                } : null;
    }
I don't see where `unmapper` is overridden.

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

PR: https://git.openjdk.java.net/jdk/pull/2229

From bpb at openjdk.java.net  Tue Jan 26 20:06:41 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 26 Jan 2021 20:06:41 GMT
Subject: RFR: 8129776: The optimized Stream returned from Files.lines
 should unmap the mapped byte buffer (if created) when closed [v2]
In-Reply-To: <nAI4603Kr1RdBu_pXheZ75wkSMNyoacbGkfIOpYpcM4=.bf88497c-b92e-472d-a327-3a3c03fcbe6f@github.com>
References: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
 <cjBR8FQj3VNSJnwGTT0GNigNv6Hg5NZWKW1Uy3vA6Ik=.ac6ce50e-9d80-4a82-9252-c55e66da113a@github.com>
 <nAI4603Kr1RdBu_pXheZ75wkSMNyoacbGkfIOpYpcM4=.bf88497c-b92e-472d-a327-3a3c03fcbe6f@github.com>
Message-ID: <BwH53iAyV-0mH_baVE8AeBU8TD7uGal3ygh1ZwpK-pM=.7397180b-2e61-4a35-9060-2225ede772dc@github.com>

On Tue, 26 Jan 2021 19:53:45 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Marked as reviewed by rriggs (Reviewer).
>
> Looks good. There is some complexity because the `Spliterator` can be obtained from the `Stream` returned by `Files.lines()`. This is not a common case but unfortunately we need to deal with it, otherwise we could just unmap when the `Stream` is closed.  There are edge cases where by splits may occur but they are not traversed, but i don't think we should be concerned about. This is on a good best-effort basis to free up the resource.
> 
> Is unmapping via `nioAccess.unmapper(b).unmap();` wired up?
> 
> In `Buffer`:
>                 @Override
>                 public UnmapperProxy unmapper(ByteBuffer bb) {
>                     if (bb instanceof MappedByteBuffer) {
>                         return ((MappedByteBuffer)bb).unmapper();
>                     } else {
>                         return null;
>                     }
>                 }
> 
> In MappedByteBuffer:
>     UnmapperProxy unmapper() {
>         return fd != null ?
>                 new UnmapperProxy() {
>                     @Override
>                     public long address() {
>                         return address;
>                     }
> 
>                     @Override
>                     public FileDescriptor fileDescriptor() {
>                         return fd;
>                     }
> 
>                     @Override
>                     public boolean isSync() {
>                         return isSync;
>                     }
> 
>                     @Override
>                     public void unmap() {
>                         throw new UnsupportedOperationException();
>                     }
>                 } : null;
>     }
> I don't see where `unmapper` is overridden.

`unmapper` looks to be overridden in `sun.nio.ch.FileChannelImpl`. Specifically, `map()` obtains the `Unmapper` instance from `mapInternal()`.

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

PR: https://git.openjdk.java.net/jdk/pull/2229

From bpb at openjdk.java.net  Wed Jan 27 01:45:39 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 27 Jan 2021 01:45:39 GMT
Subject: RFR: 8129776: The optimized Stream returned from Files.lines
 should unmap the mapped byte buffer (if created) when closed [v2]
In-Reply-To: <nAI4603Kr1RdBu_pXheZ75wkSMNyoacbGkfIOpYpcM4=.bf88497c-b92e-472d-a327-3a3c03fcbe6f@github.com>
References: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
 <cjBR8FQj3VNSJnwGTT0GNigNv6Hg5NZWKW1Uy3vA6Ik=.ac6ce50e-9d80-4a82-9252-c55e66da113a@github.com>
 <nAI4603Kr1RdBu_pXheZ75wkSMNyoacbGkfIOpYpcM4=.bf88497c-b92e-472d-a327-3a3c03fcbe6f@github.com>
Message-ID: <qDsLcxg24h7MEFf3VpBlSwcyYTalQAu1veDlN1cCbSE=.83eeee17-1107-4edf-9aab-77c90cd368a5@github.com>

On Tue, 26 Jan 2021 19:53:45 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Marked as reviewed by rriggs (Reviewer).
>
> Looks good. There is some complexity because the `Spliterator` can be obtained from the `Stream` returned by `Files.lines()`. This is not a common case but unfortunately we need to deal with it, otherwise we could just unmap when the `Stream` is closed.  There are edge cases where by splits may occur but they are not traversed, but i don't think we should be concerned about. This is on a good best-effort basis to free up the resource.
> 
> Is unmapping via `nioAccess.unmapper(b).unmap();` wired up?
> 
> In `Buffer`:
>                 @Override
>                 public UnmapperProxy unmapper(ByteBuffer bb) {
>                     if (bb instanceof MappedByteBuffer) {
>                         return ((MappedByteBuffer)bb).unmapper();
>                     } else {
>                         return null;
>                     }
>                 }
> 
> In MappedByteBuffer:
>     UnmapperProxy unmapper() {
>         return fd != null ?
>                 new UnmapperProxy() {
>                     @Override
>                     public long address() {
>                         return address;
>                     }
> 
>                     @Override
>                     public FileDescriptor fileDescriptor() {
>                         return fd;
>                     }
> 
>                     @Override
>                     public boolean isSync() {
>                         return isSync;
>                     }
> 
>                     @Override
>                     public void unmap() {
>                         throw new UnsupportedOperationException();
>                     }
>                 } : null;
>     }
> I don't see where `unmapper` is overridden.

No, unmapping via `nioAccess.unmapper(b).unmap()` is not wired up. Investigating why.

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

PR: https://git.openjdk.java.net/jdk/pull/2229

From chegar at openjdk.java.net  Wed Jan 27 14:11:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 27 Jan 2021 14:11:42 GMT
Subject: Integrated: 8257074 Update the ByteBuffers micro benchmark
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <RQRgt7w_ZF2VE2OVyWA94k_5JJc_zcbuQRDeuZ5z6Ug=.76462fa3-0550-483b-bfca-f18c25ec67ca@github.com>

On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

This pull request has now been integrated.

Changeset: ac276bb3
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ac276bb3
Stats:     2771 lines in 11 files changed: 2612 ins; 9 del; 150 mod

8257074: Update the ByteBuffers micro benchmark

Reviewed-by: redestad, dfuchs, jvernee, bpb

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

PR: https://git.openjdk.java.net/jdk/pull/1430

From mcimadamore at openjdk.java.net  Wed Jan 27 17:37:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 27 Jan 2021 17:37:40 GMT
Subject: RFR: 8129776: The optimized Stream returned from Files.lines
 should unmap the mapped byte buffer (if created) when closed [v2]
In-Reply-To: <qDsLcxg24h7MEFf3VpBlSwcyYTalQAu1veDlN1cCbSE=.83eeee17-1107-4edf-9aab-77c90cd368a5@github.com>
References: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
 <cjBR8FQj3VNSJnwGTT0GNigNv6Hg5NZWKW1Uy3vA6Ik=.ac6ce50e-9d80-4a82-9252-c55e66da113a@github.com>
 <nAI4603Kr1RdBu_pXheZ75wkSMNyoacbGkfIOpYpcM4=.bf88497c-b92e-472d-a327-3a3c03fcbe6f@github.com>
 <qDsLcxg24h7MEFf3VpBlSwcyYTalQAu1veDlN1cCbSE=.83eeee17-1107-4edf-9aab-77c90cd368a5@github.com>
Message-ID: <D3q4-YhKV7sE3_iQOjF9eiIrAU2ei26C5b9y3843KjI=.4b0102f1-f62b-44c3-a57c-153d1342c46d@github.com>

On Wed, 27 Jan 2021 01:42:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> No, unmapping via `nioAccess.unmapper(b).unmap()` is not wired up. Investigating why.

MappedByteBuffer::unmapper is only used (AFAIK) from AbstractMemorySegmentImpl::ofBuffer. When creating a segment view over a buffer, we need to recover mapping info - but close() on the returned segment is a no-op. So we don't _need_ the unmap() method to be wired up - although it doesn't hurt for it to be wired up, if desired.

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

PR: https://git.openjdk.java.net/jdk/pull/2229

From bpb at openjdk.java.net  Wed Jan 27 19:32:07 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 27 Jan 2021 19:32:07 GMT
Subject: RFR: 8129776: The optimized Stream returned from Files.lines
 should unmap the mapped byte buffer (if created) when closed [v3]
In-Reply-To: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
References: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
Message-ID: <xvL_q_NXNaVl-hZKEzDZ4CZJwlc4mblaNF5GbUGcCns=.0a8a8481-947e-4b2a-bcae-d2f183204c44@github.com>

> Please review this proposed change to unmap the mapped buffer shared between the root and sub-spliterators used in the optimized `Stream` implementation returned by `Files.lines()`. A reference counter is added to track the total number of spliterators sharing the buffer. It is set to 1 when the shared buffer is created, and incremented each time a sub-spliterator is created. It is decremented when traversing begins or when the spliterator is closed. If the counter is zero after it is decremented then the shared buffer is unmapped.

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

  8129776: Wire up MappedByteBuffer.unmapper().unmap()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2229/files
  - new: https://git.openjdk.java.net/jdk/pull/2229/files/36c34a5d..e2b0219f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2229&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2229&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/2229

From psandoz at openjdk.java.net  Wed Jan 27 22:03:43 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 27 Jan 2021 22:03:43 GMT
Subject: RFR: 8129776: The optimized Stream returned from Files.lines
 should unmap the mapped byte buffer (if created) when closed [v3]
In-Reply-To: <xvL_q_NXNaVl-hZKEzDZ4CZJwlc4mblaNF5GbUGcCns=.0a8a8481-947e-4b2a-bcae-d2f183204c44@github.com>
References: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
 <xvL_q_NXNaVl-hZKEzDZ4CZJwlc4mblaNF5GbUGcCns=.0a8a8481-947e-4b2a-bcae-d2f183204c44@github.com>
Message-ID: <xsnV3AQR72ROClbX7RpONUE6k3dGpvuZqb0jscWPdTg=.a1942451-519e-49ac-8d1c-f05cb8c54a4f@github.com>

On Wed, 27 Jan 2021 19:32:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this proposed change to unmap the mapped buffer shared between the root and sub-spliterators used in the optimized `Stream` implementation returned by `Files.lines()`. A reference counter is added to track the total number of spliterators sharing the buffer. It is set to 1 when the shared buffer is created, and incremented each time a sub-spliterator is created. It is decremented when traversing begins or when the spliterator is closed. If the counter is zero after it is decremented then the shared buffer is unmapped.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8129776: Wire up MappedByteBuffer.unmapper().unmap()

Marked as reviewed by psandoz (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2229

From lihuaming3 at huawei.com  Thu Jan 28 00:49:29 2021
From: lihuaming3 at huawei.com (lihuaming (A))
Date: Thu, 28 Jan 2021 00:49:29 +0000
Subject: (fc) FileChannel.transferFrom/transferFromArbitraryChannel to
 return -1 at some error condition
Message-ID: <FF52E71F75D5A341BDD9AB1622091FA5012103D3@DGGEML523-MBX.china.huawei.com>

Hi Everyone,

in FileChannel.transferFromArbitraryChannel, when src.read returns -1, it means "the channel has reached end-of-stream", it could be a socket underlying is reset by peer host, or some other conditions. But this "-1" is completely hidden when transferFromArbitraryChannel returns back to File.Channel.transferFrom.

Would it better to return -1 in FileChannel.transferFrom/transferFromArbitraryChannel when src.read returns -1 and tw is 0?

The reason for such a request is: We met some condition where user is relying on Channel.isOpen to tell if the underlying socket is usable (I know this is not the expected behavior) and then call FileChannel.transferFrom. it looks like following code snippet:
while (srcSocketChannel.isOpen()) {
  long l = fileChannel.transferFrom(srcSocketChannel,...);
  if (l == -1) { // break out the while loop }
}
There is one condition, where peer side has closed the underlying socket, at this situation, the above loop will be a infinite loop.

I think it's more friendly for end user if we could change the behavior of FileChannel.transferFrom/transferFromArbitraryChannel to return -1 when src.read returns -1 and tw is 0.

How do you think about it?
It's tracked by https://bugs.openjdk.java.net/browse/JDK-8260486

Thanks,
Hamlin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210128/9a13ada4/attachment-0001.htm>

From Alan.Bateman at oracle.com  Thu Jan 28 08:19:27 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 28 Jan 2021 08:19:27 +0000
Subject: (fc) FileChannel.transferFrom/transferFromArbitraryChannel to
 return -1 at some error condition
In-Reply-To: <FF52E71F75D5A341BDD9AB1622091FA5012103D3@DGGEML523-MBX.china.huawei.com>
References: <FF52E71F75D5A341BDD9AB1622091FA5012103D3@DGGEML523-MBX.china.huawei.com>
Message-ID: <f0d14384-b663-7398-439d-fd2657470617@oracle.com>

On 28/01/2021 00:49, lihuaming (A) wrote:
>
> Hi Everyone,
>
> in FileChannel.transferFromArbitraryChannel, when src.read returns -1, 
> it means "the channel has reached end-of-stream", it could be a socket 
> underlying is reset by peer host, or some other conditions. But this 
> "-1" is completely hidden when transferFromArbitraryChannel returns 
> back to File.Channel.transferFrom.
>
> Would it better to return -1 in 
> FileChannel.transferFrom/transferFromArbitraryChannel when src.read 
> returns -1 and tw is 0?
>
>
Hi Hamlin,

The transferFrom method returns the number of bytes written to the file. 
Changing the spec to allow it return -1 would be an incompatible change 
and could potentially break usages that keep a running total of bytes 
transferred.

Can you expand a bit on the scenario? If the underlying connection has 
been reset or there is another error then I would expect the read from 
the source channel to fail (SocketException "connection reset" for 
example). This is different to the peer closing the connection 
gracefully where reading from the source channel returns -1/EOF and 
there are no bytes written to the file.

-Alan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210128/779b080b/attachment.htm>

From lihuaming3 at huawei.com  Fri Jan 29 12:51:32 2021
From: lihuaming3 at huawei.com (lihuaming (A))
Date: Fri, 29 Jan 2021 12:51:32 +0000
Subject: =?gb2312?B?tPC4tDogKGZjKSBGaWxlQ2hhbm5lbC50cmFuc2ZlckZyb20vdHJhbnNmZXJG?=
 =?gb2312?B?cm9tQXJiaXRyYXJ5Q2hhbm5lbCB0byByZXR1cm4gLTEgYXQgc29tZSBlcnJv?=
 =?gb2312?Q?r_condition?=
In-Reply-To: <f0d14384-b663-7398-439d-fd2657470617@oracle.com>
References: <FF52E71F75D5A341BDD9AB1622091FA5012103D3@DGGEML523-MBX.china.huawei.com>
 <f0d14384-b663-7398-439d-fd2657470617@oracle.com>
Message-ID: <FF52E71F75D5A341BDD9AB1622091FA501211937@DGGEML523-MBX.china.huawei.com>

(Sorry for the format, I had some trouble to configure thunderbird in my environment)

Hi Hamlin,

The transferFrom method returns the number of bytes written to the file. Changing the spec to allow it return -1 would be an incompatible change and could potentially break usages that keep a running total of bytes transferred.
Hi Alan,
Yes, I think so too. But still like to see if we can improve it a little bit.

Can you expand a bit on the scenario? If the underlying connection has been reset or there is another error then I would expect the read from the source channel to fail (SocketException "connection reset" for example). This is different to the peer closing the connection gracefully where reading from the source channel returns -1/EOF and there are no bytes written to the file.
Here is a simple demo, I don't use FileChannel.transferFrom directly, but I hope I can clarify the situation.
When ServerHangHttp and Client are up for a while (please check the bottom), no matter Server close the socket explicitly or kill by "kill -9 xxx", the client side will print out "[client] read : -1" continuously. so, if we are using FileChannel.transferFrom which will call transferFromArbitraryChannel which will call ReadableByteChannel.read, ReadableByteChannel.read will return -1, but transferFromArbitraryChannel will return 0, so as FileChannel.transferFrom. Based on this return value, following while loop will be a infinite loop, and user don't want to call something like "call sth like srcSocketChannel.read(...)", please check the reason in comments below.
while (srcSocketChannel.isOpen()) {
  long l = fileChannel.transferFrom(srcSocketChannel,...);
  // user could call sth like srcSocketChannel.read(...), and expect it return -1, and break the loop, but it will be unacceptable for some program, where they would like to very quick copy, so called "zero" copy through fileChannel.transferFrom, and they don't want to add an extra check like "srcSocketChannel.read(...)"
  if (l == -1) { // break out the while loop }
}
At this situation, I think it's more friendly to have fileChannel.transferFrom returns -1.
Thanks,
Hamlin
=========== ServerHangHttp and Client ==============
public class ServerHangHttp {
        public static void main(String args[]) throws Exception {
                ServerSocketChannel server = ServerSocketChannel.open();
                server.bind(new InetSocketAddress("127.0.0.1", 9876));
                System.out.println("            waiting for client...");
                SocketChannel client = server.accept();
                System.out.println("            get client connection successfully");
                System.out.println("            socket: " + client);
                int i = 0;
                while (client.isOpen()) {
                        System.out.println("            write some bytes to client");
                        client.write(ByteBuffer.wrap("abc".getBytes()));
                        Thread.sleep(1000);
                        /*
                         * if (++i == 10) {
                                System.out.println("            socket is closed");
                                client.close();
                                break;
                        }*/
                }

        }
}
public class Client {
        public static void main(String args[]) throws Exception {
                SocketChannel client = SocketChannel.open(new InetSocketAddress("127.0.0.1", 9876));
                System.out.println("[client] socket: " + client);
                int i = 0;
                ByteBuffer buf = ByteBuffer.allocate(1000);
                while (true) {
                        int x = client.read(buf);
                        System.out.println("[client] read : " + x);
                        Thread.sleep(1000);
                }
        }
}


-Alan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210129/221df8ea/attachment.htm>

From Alan.Bateman at oracle.com  Fri Jan 29 17:07:13 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 29 Jan 2021 17:07:13 +0000
Subject: =?UTF-8?B?UmU6IOetlOWkjTogKGZjKSBGaWxlQ2hhbm5lbC50cmFuc2ZlckZyb20v?=
 =?UTF-8?Q?transferFromArbitraryChannel_to_return_-1_at_some_error_condition?=
In-Reply-To: <FF52E71F75D5A341BDD9AB1622091FA501211937@DGGEML523-MBX.china.huawei.com>
References: <FF52E71F75D5A341BDD9AB1622091FA5012103D3@DGGEML523-MBX.china.huawei.com>
 <f0d14384-b663-7398-439d-fd2657470617@oracle.com>
 <FF52E71F75D5A341BDD9AB1622091FA501211937@DGGEML523-MBX.china.huawei.com>
Message-ID: <d032afdb-6be0-37a4-a343-d7be3e4291ca@oracle.com>

On 29/01/2021 12:51, lihuaming (A) wrote:
>
> Here is a simple demo, I don't use FileChannel.transferFrom directly, 
> but I hope I can clarify the situation.
>
> When ServerHangHttp and Client are up for a while (please check the 
> bottom), no matter Server close the socket explicitly or kill by "kill 
> -9 xxx", the client side will print out "[client] read : -1" 
> continuously. so, if we are using FileChannel.transferFrom which will 
> call transferFromArbitraryChannel which will call 
> ReadableByteChannel.read, ReadableByteChannel.read will return -1, but 
> transferFromArbitraryChannel will return 0, so as 
> FileChannel.transferFrom. Based on this return value, following while 
> loop will be a infinite loop, and user don't want to call something 
> like "call sth like srcSocketChannel.read(...)", please check the 
> reason in comments below.
>
> while (srcSocketChannel.isOpen()) {
>
> ? long l = fileChannel.transferFrom(srcSocketChannel,...);
> ? // user could call sth like srcSocketChannel.read(...), and expect 
> it return -1, and break the loop, but it will be unacceptable for some 
> program, where they would like to very quick copy, so called "zero" 
> copy through fileChannel.transferFrom, and they don't want to add an 
> extra check like "srcSocketChannel.read(...)"
> ? if (l == -1) { // break out the while loop }
>
> }
>
> At this situation, I think it's more friendly to have 
> fileChannel.transferFrom returns -1.
>
The Client in the reproducer has a bug in that it will call read with 0 
remaining bytes once it has read 100 bytes in total. So I would expect 
it will eventually spin reading 0 rather than -1. If the server does 
terminate and close the connection gracefully then the client will spin 
reading -1 but only if reads -1/EOF before 1000 bytes are read. For 
transferFrom reading from an arbitrary channel then it may read bytes 
before EOF, in which case it will write those bytes to the file and 
return the number of bytes written/transferred. If called again then it 
will read again and just 0 because there are no bytes transferred. I 
don't see how we can could change this API without breaking existing 
usages that keeping a running code.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210129/357177d0/attachment-0001.htm>

From bpb at openjdk.java.net  Fri Jan 29 21:32:52 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 29 Jan 2021 21:32:52 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename
 extension
Message-ID: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>

Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`.

The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.)

All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension.

Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero.

The behavior of the proposed method for some example cases is as:

.              -> 
..             -> 
.a.b           -> b
......         -> 
.....a         -> a
....a.b        -> b
..foo          -> foo
test.rb        -> rb
a/b/d/test.rb  -> rb
.a/b/d/test.rb -> rb
foo.           -> 
test           -> 
.profile       -> 
.profile.sh    -> sh
..foo          -> foo
.....foo       -> foo
.vimrc         -> 
test.          -> 
test..         -> 
test...        -> 
image.jpg      -> jpg
music.mp3      -> mp3
video.mp4      -> mp4
document.txt   -> txt

If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.

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

Commit messages:
 - 8057113: (fs) Path should have a method to obtain the filename extension

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

PR: https://git.openjdk.java.net/jdk/pull/2319

From sebastian.stenzel at gmail.com  Fri Jan 29 21:48:29 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Fri, 29 Jan 2021 22:48:29 +0100
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension
In-Reply-To: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
Message-ID: <70FE5E64-D801-4C32-91C1-417A38CBEAF0@gmail.com>


> Am 29.01.2021 um 22:33 schrieb Brian Burkhalter <bpb at openjdk.java.net>:
> 
> The behavior of the proposed method for some example cases is as:
> 
> .              -> 
> ..             -> 
> .a.b           -> b
> ......         -> 
> .....a         -> a
> ....a.b        -> b
> ..foo          -> foo
> test.rb        -> rb
> a/b/d/test.rb  -> rb
> .a/b/d/test.rb -> rb
> foo.           -> 
> test           -> 
> .profile       -> 
> .profile.sh    -> sh
> ..foo          -> foo
> .....foo       -> foo
> .vimrc         -> 
> test.          -> 
> test..         -> 
> test...        -> 
> image.jpg      -> jpg
> music.mp3      -> mp3
> video.mp4      -> mp4
> document.txt   -> txt
> 
> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.

I would propose to add two more test cases:

foo.tar.gz ? gz
foo.bar. ? 

From brian.burkhalter at oracle.com  Fri Jan 29 22:03:08 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 29 Jan 2021 14:03:08 -0800
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension
In-Reply-To: <70FE5E64-D801-4C32-91C1-417A38CBEAF0@gmail.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <70FE5E64-D801-4C32-91C1-417A38CBEAF0@gmail.com>
Message-ID: <F2B1E801-F2B1-4FEF-952C-7F8CF4E94C83@oracle.com>

That is what happens now. I can include these and the previous ones in a test later.

Thanks ...

> On Jan 29, 2021, at 1:48 PM, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
> 
> I would propose to add two more test cases:
> 
> foo.tar.gz ? gz
> foo.bar. ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210129/5392b78d/attachment.htm>

From rriggs at openjdk.java.net  Fri Jan 29 22:07:42 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 29 Jan 2021 22:07:42 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension
In-Reply-To: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
Message-ID: <iuf12RvTYzRk8PSskmiu8dW72NG2AL2-2fQGqt2nauE=.b300b495-8f79-4d0c-993d-39e07f34d872@github.com>

On Fri, 29 Jan 2021 21:13:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`.
> 
> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.)
> 
> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension.
> 
> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero.
> 
> The behavior of the proposed method for some example cases is as:
> 
> .              -> 
> ..             -> 
> .a.b           -> b
> ......         -> 
> .....a         -> a
> ....a.b        -> b
> ..foo          -> foo
> test.rb        -> rb
> a/b/d/test.rb  -> rb
> .a/b/d/test.rb -> rb
> foo.           -> 
> test           -> 
> .profile       -> 
> .profile.sh    -> sh
> ..foo          -> foo
> .....foo       -> foo
> .vimrc         -> 
> test.          -> 
> test..         -> 
> test...        -> 
> foo.tar.gz     -> gz
> foo.bar.       -> 
> image.jpg      -> jpg
> music.mp3      -> mp3
> video.mp4      -> mp4
> document.txt   -> txt
> 
> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.

The definition is easy to understand and simple enough to avoid confusion.

src/java.base/share/classes/java/nio/file/Path.java line 258:

> 256:      * is returned.  This will occur if the file name has length less than two,
> 257:      * only the first character is a dot, or the last character is a dot.
> 258:      *

Add the case where there is no '.' to be explicit.

src/java.base/share/classes/java/nio/file/Path.java line 267:

> 265:      *     filename.substring(filename.lastIndexOf('.') + 1);
> 266:      * }</pre>
> 267:      *

The Implspec fragment should be more complete. The preconditions in the prose are likely to be ignored by the reader.

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

PR: https://git.openjdk.java.net/jdk/pull/2319

From forax at univ-mlv.fr  Fri Jan 29 22:10:47 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 29 Jan 2021 23:10:47 +0100 (CET)
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension
In-Reply-To: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
Message-ID: <1143463981.1392833.1611958247800.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Brian Burkhalter" <bpb at openjdk.java.net>
> ?: "nio-dev" <nio-dev at openjdk.java.net>
> Envoy?: Vendredi 29 Janvier 2021 22:32:52
> Objet: RFR: 8057113: (fs) Path should have a method to obtain the filename extension

> Please review this proposed change to add a method
> `java.nio.file.Path.getExtension()`. This was initially discussed in the thread
> http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This
> method would return the filename extension of the file name of the `Path`. The
> extension is defined to be the portion of the file name after the last dot
> `(?.?)`.
> 
> The definitions of file extension for about fifteen platforms and languages were
> surveyed to try to find a reasonable compromise for the definition of
> extension. The most common definition was the last segment of the name
> including and after the last dot. The second definition omitted the last dot
> from the extension. Java-related platforms all exclude the last dot. (One
> divergent definition in the internal Java NIO method
> `AbstractFileTypeDetector.getExtension(String)` defines the extension as the
> part after the *first* dot.)
> 
> All examined cases define the extension to be an empty string if it cannot be
> determined. None of these cases used `null` to represent an indeterminate
> extension.
> 
> Little in the way of specifying behavior for special cases (consisting mainly of
> file names with one or more leading dots) was found. Most definitions concern
> themselves only with the last dot and what comes after it and ignore leading
> dots altogether. A few definitions ignore a leading dot at the zeroth
> character. The current proposal ignores a dot at character zero.
> 
> The behavior of the proposed method for some example cases is as:
> 
> .              ->
> ..             ->
> .a.b           -> b
> ......         ->
> .....a         -> a
> ....a.b        -> b
> ..foo          -> foo
> test.rb        -> rb
> a/b/d/test.rb  -> rb
> .a/b/d/test.rb -> rb
> foo.           ->
> test           ->
> .profile       ->
> .profile.sh    -> sh
> ..foo          -> foo
> .....foo       -> foo
> .vimrc         ->
> test.          ->
> test..         ->
> test...        ->
> image.jpg      -> jpg
> music.mp3      -> mp3
> video.mp4      -> mp4
> document.txt   -> txt
> 
> If the specification can be agreed upon, then a test will be added to this PR
> and a corresponding CSR will be filed.

Thanks for doing this !

Usually in JDK codes, the return value is returned early instead of being stored in a local variable and then returned.
So a code like below is more usual.

   default String getExtension() {
        String name = getFileName().toString();
        int length = name.length();

        // Indeterminate if name is too short or equal to "..".
        if (length > 1 && !name.equals("..")) {
            int lastDotIndex = name.lastIndexOf('.');
            // Indeterminate if no dot or found at last or only the first index
            if (lastDotIndex > 0 && lastDotIndex < length - 1) {
                return name.substring(lastDotIndex + 1);
            }
        }
        return "";
    }

regards,
R?mi

> 
> -------------
> 
> Commit messages:
> - 8057113: (fs) Path should have a method to obtain the filename extension
> 
> Changes: https://git.openjdk.java.net/jdk/pull/2319/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2319&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8057113
>  Stats: 37 lines in 1 file changed: 36 ins; 0 del; 1 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/2319.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2319/head:pull/2319
> 
> PR: https://git.openjdk.java.net/jdk/pull/2319

From bpb at openjdk.java.net  Fri Jan 29 22:12:44 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 29 Jan 2021 22:12:44 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension
In-Reply-To: <iuf12RvTYzRk8PSskmiu8dW72NG2AL2-2fQGqt2nauE=.b300b495-8f79-4d0c-993d-39e07f34d872@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <iuf12RvTYzRk8PSskmiu8dW72NG2AL2-2fQGqt2nauE=.b300b495-8f79-4d0c-993d-39e07f34d872@github.com>
Message-ID: <q1C6Dc7uLUCuGI-7Fh9T2B1gQU0Xnu-xIgpT7lvdmqQ=.4b28e841-22af-4bd8-a1e0-e94c8509962a@github.com>

On Fri, 29 Jan 2021 21:51:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`.
>> 
>> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.)
>> 
>> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension.
>> 
>> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero.
>> 
>> The behavior of the proposed method for some example cases is as:
>> 
>> .              -> 
>> ..             -> 
>> .a.b           -> b
>> ......         -> 
>> .....a         -> a
>> ....a.b        -> b
>> ..foo          -> foo
>> test.rb        -> rb
>> a/b/d/test.rb  -> rb
>> .a/b/d/test.rb -> rb
>> foo.           -> 
>> test           -> 
>> .profile       -> 
>> .profile.sh    -> sh
>> ..foo          -> foo
>> .....foo       -> foo
>> .vimrc         -> 
>> test.          -> 
>> test..         -> 
>> test...        -> 
>> foo.tar.gz     -> gz
>> foo.bar.       -> 
>> image.jpg      -> jpg
>> music.mp3      -> mp3
>> video.mp4      -> mp4
>> document.txt   -> txt
>> 
>> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.
>
> src/java.base/share/classes/java/nio/file/Path.java line 258:
> 
>> 256:      * is returned.  This will occur if the file name has length less than two,
>> 257:      * only the first character is a dot, or the last character is a dot.
>> 258:      *
> 
> Add the case where there is no '.' to be explicit.

Good point; will do.

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

PR: https://git.openjdk.java.net/jdk/pull/2319

From brian.burkhalter at oracle.com  Fri Jan 29 22:14:50 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 29 Jan 2021 14:14:50 -0800
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension
In-Reply-To: <1143463981.1392833.1611958247800.JavaMail.zimbra@u-pem.fr>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <1143463981.1392833.1611958247800.JavaMail.zimbra@u-pem.fr>
Message-ID: <05A14945-6BBD-4C1D-A363-9BCD0C3435D9@oracle.com>


> On Jan 29, 2021, at 2:10 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Thanks for doing this !

You?re welcome.

> Usually in JDK codes, the return value is returned early instead of being stored in a local variable and then returned.
> So a code like below is more usual.

Will change; thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210129/ca1c2326/attachment.htm>

From rriggs at openjdk.java.net  Fri Jan 29 22:15:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 29 Jan 2021 22:15:41 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension
In-Reply-To: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
Message-ID: <DT0SprapH6Uam8_-fuYCTxzAk4rAqsGdpm6YzZCWzmE=.f4447d03-5d97-4f02-8a64-362e0a21e54f@github.com>

On Fri, 29 Jan 2021 21:13:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`.
> 
> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.)
> 
> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension.
> 
> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero.
> 
> The behavior of the proposed method for some example cases is as:
> 
> .              -> 
> ..             -> 
> .a.b           -> b
> ......         -> 
> .....a         -> a
> ....a.b        -> b
> ..foo          -> foo
> test.rb        -> rb
> a/b/d/test.rb  -> rb
> .a/b/d/test.rb -> rb
> foo.           -> 
> test           -> 
> .profile       -> 
> .profile.sh    -> sh
> ..foo          -> foo
> .....foo       -> foo
> .vimrc         -> 
> test.          -> 
> test..         -> 
> test...        -> 
> foo.tar.gz     -> gz
> foo.bar.       -> 
> image.jpg      -> jpg
> music.mp3      -> mp3
> video.mp4      -> mp4
> document.txt   -> txt
> 
> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.

src/java.base/share/classes/java/nio/file/Path.java line 278:

> 276:         // Indeterminate if name is too short or equal to "..".
> 277:         if (length > 1 && !name.equals("..")) {
> 278:             int lastDotIndex = name.lastIndexOf('.');

Since there are no strings of length 0..2, is it sufficient to check for length > 2.
(Instead of the string compare equals("..").

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

PR: https://git.openjdk.java.net/jdk/pull/2319

From bpb at openjdk.java.net  Fri Jan 29 22:25:41 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 29 Jan 2021 22:25:41 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension
In-Reply-To: <DT0SprapH6Uam8_-fuYCTxzAk4rAqsGdpm6YzZCWzmE=.f4447d03-5d97-4f02-8a64-362e0a21e54f@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <DT0SprapH6Uam8_-fuYCTxzAk4rAqsGdpm6YzZCWzmE=.f4447d03-5d97-4f02-8a64-362e0a21e54f@github.com>
Message-ID: <3S92nkcCBDPgT2zytmFpiexJkN89K6vuXbe-V1Tm_gw=.68c00c66-ba7e-475c-ba13-a2de52e6b3e2@github.com>

On Fri, 29 Jan 2021 22:12:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`.
>> 
>> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.)
>> 
>> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension.
>> 
>> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero.
>> 
>> The behavior of the proposed method for some example cases is as:
>> 
>> .              -> 
>> ..             -> 
>> .a.b           -> b
>> ......         -> 
>> .....a         -> a
>> ....a.b        -> b
>> ..foo          -> foo
>> test.rb        -> rb
>> a/b/d/test.rb  -> rb
>> .a/b/d/test.rb -> rb
>> foo.           -> 
>> test           -> 
>> .profile       -> 
>> .profile.sh    -> sh
>> ..foo          -> foo
>> .....foo       -> foo
>> .vimrc         -> 
>> test.          -> 
>> test..         -> 
>> test...        -> 
>> foo.tar.gz     -> gz
>> foo.bar.       -> 
>> image.jpg      -> jpg
>> music.mp3      -> mp3
>> video.mp4      -> mp4
>> document.txt   -> txt
>> 
>> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.
>
> src/java.base/share/classes/java/nio/file/Path.java line 278:
> 
>> 276:         // Indeterminate if name is too short or equal to "..".
>> 277:         if (length > 1 && !name.equals("..")) {
>> 278:             int lastDotIndex = name.lastIndexOf('.');
> 
> Since there are no strings of length 0..2, is it sufficient to check for length > 2.
> (Instead of the string compare equals("..").

Nice point! Considering that the strings of length 2 are `.x`, `xy`, and `x.` where `x` and `y` are characters which are not `'.'`, then I concur.

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

PR: https://git.openjdk.java.net/jdk/pull/2319

From bpb at openjdk.java.net  Fri Jan 29 23:13:55 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 29 Jan 2021 23:13:55 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v2]
In-Reply-To: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
Message-ID: <lXnihqoSeE9UoeatdQ3B2XgZWyrzSkv3DjDSSdYiZ3I=.79baefd9-45cf-40bb-bd31-7768394d5f48@github.com>

> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`.
> 
> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.)
> 
> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension.
> 
> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero.
> 
> The behavior of the proposed method for some example cases is as:
> 
> .              -> 
> ..             -> 
> .a.b           -> b
> ......         -> 
> .....a         -> a
> ....a.b        -> b
> ..foo          -> foo
> test.rb        -> rb
> a/b/d/test.rb  -> rb
> .a/b/d/test.rb -> rb
> foo.           -> 
> test           -> 
> .profile       -> 
> .profile.sh    -> sh
> ..foo          -> foo
> .....foo       -> foo
> .vimrc         -> 
> test.          -> 
> test..         -> 
> test...        -> 
> foo.tar.gz     -> gz
> foo.bar.       -> 
> image.jpg      -> jpg
> music.mp3      -> mp3
> video.mp4      -> mp4
> document.txt   -> txt
> 
> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.

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

  8057113: Changes pursuant to PR conversation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2319/files
  - new: https://git.openjdk.java.net/jdk/pull/2319/files/eb1f83fd..7c3d0ff7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2319&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2319&range=00-01

  Stats: 16 lines in 1 file changed: 4 ins; 3 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2319.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2319/head:pull/2319

PR: https://git.openjdk.java.net/jdk/pull/2319

From lihuaming3 at huawei.com  Sat Jan 30 00:56:58 2021
From: lihuaming3 at huawei.com (Hamlin)
Date: Sat, 30 Jan 2021 08:56:58 +0800
Subject: (fc) FileChannel.transferFrom/transferFromArbitraryChannel to
 return -1 at some error condition
In-Reply-To: <f0d14384-b663-7398-439d-fd2657470617@oracle.com>
References: <FF52E71F75D5A341BDD9AB1622091FA5012103D3@DGGEML523-MBX.china.huawei.com>
 <f0d14384-b663-7398-439d-fd2657470617@oracle.com>
Message-ID: <5de3436d-7ec7-1100-674f-31ac000dcb01@huawei.com>

(send out the same message in thunderbird)


? 2021/1/28 16:19, Alan Bateman ??:
> On 28/01/2021 00:49, lihuaming (A) wrote:
>>
>> Hi Everyone,
>>
>> in FileChannel.transferFromArbitraryChannel, when src.read returns 
>> -1, it means "the channel has reached end-of-stream", it could be a 
>> socket underlying is reset by peer host, or some other conditions. 
>> But this "-1" is completely hidden when transferFromArbitraryChannel 
>> returns back to File.Channel.transferFrom.
>>
>> Would it better to return -1 in 
>> FileChannel.transferFrom/transferFromArbitraryChannel when src.read 
>> returns -1 and tw is 0?
>>
>>
> Hi Hamlin,
>
> The transferFrom method returns the number of bytes written to the 
> file. Changing the spec to allow it return -1 would be an incompatible 
> change and could potentially break usages that keep a running total of 
> bytes transferred.

Hi Alan,

Yes, I think so too. But still like to see if we can improve it a little 
bit.

>
> Can you expand a bit on the scenario? If the underlying connection has 
> been reset or there is another error then I would expect the read from 
> the source channel to fail (SocketException "connection reset" for 
> example). This is different to the peer closing the connection 
> gracefully where reading from the source channel returns -1/EOF and 
> there are no bytes written to the file.

Here is a simple demo, I don't use FileChannel.transferFrom directly, 
but I hope I can clarify the situation.

When ServerHangHttp and Client are up for a while (please check the 
bottom), no matter Server close the socket explicitly or kill by "kill 
-9 xxx", the client side will print out "[client] read : -1" 
continuously. so, if we are using FileChannel.transferFrom which will 
call transferFromArbitraryChannel which will call 
ReadableByteChannel.read, ReadableByteChannel.read will return -1, but 
transferFromArbitraryChannel will return 0, so as 
FileChannel.transferFrom. Based on this return value, following while 
loop will be a infinite loop, and user don't want to call something like 
"call sth like srcSocketChannel.read(...)", please check the reason in 
comments below.

while (srcSocketChannel.isOpen()) {
   long l = fileChannel.transferFrom(srcSocketChannel,...);
   // user could call sth like srcSocketChannel.read(...), and expect it return -1, and break the loop, but it will be unacceptable for some program, where they would like to very quick copy, so called "zero" copy through fileChannel.transferFrom, and they don't want to add an extra check like "srcSocketChannel.read(...)"
 ? if (l == -1) { // break out the while loop }
}

At this situation, I think it's more friendly to have 
fileChannel.transferFrom returns -1.

Thanks,

Hamlin

=========== ServerHangHttp and Client ==============

public class ServerHangHttp {
 ??????? public static void main(String args[]) throws Exception {
 ??????????????? ServerSocketChannel server = ServerSocketChannel.open();
 ??????????????? server.bind(new InetSocketAddress("127.0.0.1", 9876));
 ??????????????? System.out.println("??????????? waiting for client...");
 ??????????????? SocketChannel client = server.accept();
 ??????????????? System.out.println("??????????? get client connection 
successfully");
 ??????????????? System.out.println("??????????? socket: " + client);
 ??????????????? int i = 0;
 ??????????????? while (client.isOpen()) {
 ??????????????????????? System.out.println("??????????? write some 
bytes to client");
client.write(ByteBuffer.wrap("abc".getBytes()));
 ??????????????????????? Thread.sleep(1000);
 ??????????????????????? /*
 ???????????????????????? * if (++i == 10) {
 ??????????????????????????????? System.out.println(" socket is closed");
 ??????????????????????????????? client.close();
 ??????????????????????????????? break;
 ??????????????????????? }*/
 ??????????????? }

 ??????? }
}

public class Client {
 ??????? public static void main(String args[]) throws Exception {
 ??????????????? SocketChannel client = SocketChannel.open(new 
InetSocketAddress("127.0.0.1", 9876));
 ??????????????? System.out.println("[client] socket: " + client);
 ??????????????? int i = 0;
 ??????????????? ByteBuffer buf = ByteBuffer.allocate(1000);
 ??????????????? while (true) {
 ??????????????????????? int x = client.read(buf);
 ??????????????????????? System.out.println("[client] read : " + x);
 ??????????????????????? Thread.sleep(1000);
 ??????????????? }
 ??????? }
}


>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210130/2e4b24e9/attachment.htm>

From lihuaming3 at huawei.com  Sat Jan 30 07:52:59 2021
From: lihuaming3 at huawei.com (lihuaming (A))
Date: Sat, 30 Jan 2021 07:52:59 +0000
Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IChmYykgRmlsZUNoYW5uZWwudHJhbnNmZXJGcm9t?=
 =?utf-8?B?L3RyYW5zZmVyRnJvbUFyYml0cmFyeUNoYW5uZWwgdG8gcmV0dXJuIC0xIGF0?=
 =?utf-8?Q?_some_error_condition?=
In-Reply-To: <d032afdb-6be0-37a4-a343-d7be3e4291ca@oracle.com>
References: <FF52E71F75D5A341BDD9AB1622091FA5012103D3@DGGEML523-MBX.china.huawei.com>
 <f0d14384-b663-7398-439d-fd2657470617@oracle.com>
 <FF52E71F75D5A341BDD9AB1622091FA501211937@DGGEML523-MBX.china.huawei.com>
 <d032afdb-6be0-37a4-a343-d7be3e4291ca@oracle.com>
Message-ID: <FF52E71F75D5A341BDD9AB1622091FA501211B9E@DGGEML523-MBX.china.huawei.com>

Hi Alan,

Please check my comments below, I mark them with starting ###. (sorry to use the Outlook again, some emails were lost in thunderbird, don?t know why.)

???: Alan Bateman [mailto:Alan.Bateman at oracle.com]
????: 2021?1?30? 1:07
???: lihuaming (A) <lihuaming3 at huawei.com>; nio-dev at openjdk.java.net
??: Re: ??: (fc) FileChannel.transferFrom/transferFromArbitraryChannel to return -1 at some error condition

On 29/01/2021 12:51, lihuaming (A) wrote:

Here is a simple demo, I don't use FileChannel.transferFrom directly, but I hope I can clarify the situation.
When ServerHangHttp and Client are up for a while (please check the bottom), no matter Server close the socket explicitly or kill by "kill -9 xxx", the client side will print out "[client] read : -1" continuously. so, if we are using FileChannel.transferFrom which will call transferFromArbitraryChannel which will call ReadableByteChannel.read, ReadableByteChannel.read will return -1, but transferFromArbitraryChannel will return 0, so as FileChannel.transferFrom. Based on this return value, following while loop will be a infinite loop, and user don't want to call something like "call sth like srcSocketChannel.read(...)", please check the reason in comments below.
while (srcSocketChannel.isOpen()) {
  long l = fileChannel.transferFrom(srcSocketChannel,...);
  // user could call sth like srcSocketChannel.read(...), and expect it return -1, and break the loop, but it will be unacceptable for some program, where they would like to very quick copy, so called "zero" copy through fileChannel.transferFrom, and they don't want to add an extra check like "srcSocketChannel.read(...)"
  if (l == -1) { // break out the while loop }
}
At this situation, I think it's more friendly to have fileChannel.transferFrom returns -1.
The Client in the reproducer has a bug in that it will call read with 0 remaining bytes once it has read 100 bytes in total. So I would expect it will eventually spin reading 0 rather than -1.

### Sorry, please ignore this bug, I do kill the server manually shortly after it?s connected with client.

If the server does terminate and close the connection gracefully then the client will spin reading -1 but only if reads -1/EOF before 1000 bytes are read.

### Yes, as I kill the server manually, so client read will return -1.

For transferFrom reading from an arbitrary channel then it may read bytes before EOF, in which case it will write those bytes to the file and return the number of bytes written/transferred. If called again then it will read again and just 0 because there are no bytes transferred. I don't see how we can could change this API without breaking existing usages that keeping a running code.

### if the arbitrary channel was just closed by peer side, transferFrom will return 0 this time or next time, and there is no way for it knows that the underlying socket was closed, unless it calls channel.read. But for performance consideration, I think some framework/program would like to call FileChannel,transferFrom(channel, ?) only, rather than followed by a read+write just in case of channel is closed by peer side; read+write can be optimized by only do it if transferFrom(channel, ?) returns 0, but it still has some extra cost, and code is not simple and straight.
### I don?t think this is jdk bug and I do have concern about the compatibility too and explained to framework/program developers, but I can also understand their points, so want to see if there are some way to make it more friendly to framework/program developers in this situation. Hope I have made it clear ?. If there is no other better solutions, I will let them know that it?s better to modify their code.

Thanks Alan for discussion.

Hamlin



-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210130/c8e51728/attachment-0001.htm>

From Alan.Bateman at oracle.com  Sat Jan 30 08:51:30 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 30 Jan 2021 08:51:30 +0000
Subject: =?UTF-8?B?UmU6IOetlOWkjTog562U5aSNOiAoZmMpIEZpbGVDaGFubmVsLnRyYW5z?=
 =?UTF-8?Q?ferFrom/transferFromArbitraryChannel_to_return_-1_at_some_error_c?=
 =?UTF-8?Q?ondition?=
In-Reply-To: <FF52E71F75D5A341BDD9AB1622091FA501211B9E@DGGEML523-MBX.china.huawei.com>
References: <FF52E71F75D5A341BDD9AB1622091FA5012103D3@DGGEML523-MBX.china.huawei.com>
 <f0d14384-b663-7398-439d-fd2657470617@oracle.com>
 <FF52E71F75D5A341BDD9AB1622091FA501211937@DGGEML523-MBX.china.huawei.com>
 <d032afdb-6be0-37a4-a343-d7be3e4291ca@oracle.com>
 <FF52E71F75D5A341BDD9AB1622091FA501211B9E@DGGEML523-MBX.china.huawei.com>
Message-ID: <408c0fa4-cfcc-88dc-8afa-5ba07c869796@oracle.com>

On 30/01/2021 07:52, lihuaming (A) wrote:
>
> ### if the arbitrary channel was just closed by peer side, 
> transferFrom will return 0 this time or next time, and there is no way 
> for it knows that the underlying socket was closed, unless it calls 
> channel.read. But for performance consideration, I think some 
> framework/program would like to call FileChannel,transferFrom(channel, 
> ?) only, rather than followed by a read+write just in case of channel 
> is closed by peer side; read+write can be optimized by only do it if 
> transferFrom(channel, ?) returns 0, but it still has some extra cost, 
> and code is not simple and straight.
>
> ### I don?t think this is jdk bug and I do have concern about the 
> compatibility too and explained to framework/program developers, but I 
> can also understand their points, so want to see if there are some way 
> to make it more friendly to framework/program developers in this 
> situation. Hope I have made it clear J. If there is no other better 
> solutions, I will let them know that it?s better to modify their code.
>
> Thanks Alan for discussion.
>
>
Right, I think you get it. In this case the framework will need to fix 
their code.

While not the case here, I do have sympathy for those trying to using 
this API with a source channel that is configured non-blocking. As the 
method returns the number of bytes transferred (meaning read and then 
the written to the file) then it can't distinguish the EOF from the "no 
bytes available" case. This is probably something we should put into an 
@apiNote.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210130/c11babf9/attachment.htm>

From Alan.Bateman at oracle.com  Sun Jan 31 11:21:56 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 31 Jan 2021 11:21:56 +0000
Subject: JDK-8259873: (fs) Add
 java.nio.file.attribute.BasicWithKeyFileAttributeView interface
In-Reply-To: <CAFcJ+g6pL_3fUaCAQU+59QcOVSaGc-HrcyBEAW4hjpVvL0OGoQ@mail.gmail.com>
References: <CAFcJ+g6pL_3fUaCAQU+59QcOVSaGc-HrcyBEAW4hjpVvL0OGoQ@mail.gmail.com>
Message-ID: <3d8fca61-ba0f-a47c-0944-07e9a78a22d6@oracle.com>

On 19/01/2021 22:36, Renaud Paquay wrote:
> :
>
> PR 2122
> =======
>
> PR 2122 is an "in place" (i.e. no behavior or public API change) 
> implementation change in WindowsDirectoryStream: Instead of using 
> FindFirstFile 
> <https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew>,FindNextFile 
> <https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findnextfilew>, 
> the new implementation uses NtQueryDirectoryFile 
> <https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntquerydirectoryfile>, 
> which is more efficient at enumerating directory entries and allows 
> acquiring file keys for "free" with each entry.
>
I've looked through the changes in pull/2122.

This changes the implementation from using 
FindFirst/FindNextFile/FindClose to low-level DDK functions. These seem 
to be documented so moving to these functions may be okay. It would be 
useful to get some performance data with just this change if possible. 
Also it would be useful to get confirmation that there aren't any issues 
with using UNCs or mounted volumes as we've had interop problems in the 
past with SAMBA and some CIFS servers.

Adding ntifs_min.h is probably okay but would be useful to know if 
ntifs.h is the DDK only, are there are any VC++ or SDK releases that 
have this include file? We'll probably need to put the constants into 
WindowsConstants so they can be used by WindowsDirectoryStream.

There will be cleanup needed to get the patch consistent with the 
existing code. One issue is that the native functions that 
WindowsNativeDispatcher defines should map, where possible, to call on 
win32 function. This means that OpenNtQueryDirectoryInformation needs to 
be split up so that WindowsDirectoryStream calls CreateFile and then 
NtQueryDirectoryInformation with the file handle. It should be okay for 
WindowsDirectoryStream to work with NTSTATUS codes and then call 
RtlNtStatusToDosError to translate to system errors when required.

Adding fromFieldIdFullDirInformation to WindowsFileAttributes is okay 
although supplementing it with the volume serial number is a bit odd. 
The other other methods (getFileNameFromFieldIdFullDirInformation and 
getNextOffsetFromFieldIdDirInformation) are nothing to do with 
WindowsFileAttributes so shouldn't be there. WindowsDirectoryStream may 
be a better place to operation on FieldIdFullDirInformation structure or 
else introduces a new class to encapsulate an instance. This will a lot 
cleaner in the future when we have Panama.

It would also be good if you could try to keep the style, naming, and 
line lengths consistent if you can. Some of the really long 140+ 
character lines will make future reviewing of side-by-side diffs hard to 
review.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210131/3392c973/attachment.htm>

From alanb at openjdk.java.net  Sun Jan 31 12:42:45 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 31 Jan 2021 12:42:45 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v2]
In-Reply-To: <lXnihqoSeE9UoeatdQ3B2XgZWyrzSkv3DjDSSdYiZ3I=.79baefd9-45cf-40bb-bd31-7768394d5f48@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <lXnihqoSeE9UoeatdQ3B2XgZWyrzSkv3DjDSSdYiZ3I=.79baefd9-45cf-40bb-bd31-7768394d5f48@github.com>
Message-ID: <hDqwPegKOU3l6SZsTwJUlm_I6Ump0VTH9wwzQc7oDfA=.17eadc4a-bc00-4bb3-9b8d-9117b16c32f7@github.com>

On Fri, 29 Jan 2021 23:13:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`.
>> 
>> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.)
>> 
>> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension.
>> 
>> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero.
>> 
>> The behavior of the proposed method for some example cases is as:
>> 
>> .              -> 
>> ..             -> 
>> .a.b           -> b
>> ......         -> 
>> .....a         -> a
>> ....a.b        -> b
>> ..foo          -> foo
>> test.rb        -> rb
>> a/b/d/test.rb  -> rb
>> .a/b/d/test.rb -> rb
>> foo.           -> 
>> test           -> 
>> .profile       -> 
>> .profile.sh    -> sh
>> ..foo          -> foo
>> .....foo       -> foo
>> .vimrc         -> 
>> test.          -> 
>> test..         -> 
>> test...        -> 
>> foo.tar.gz     -> gz
>> foo.bar.       -> 
>> image.jpg      -> jpg
>> music.mp3      -> mp3
>> video.mp4      -> mp4
>> document.txt   -> txt
>> 
>> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8057113: Changes pursuant to PR conversation

src/java.base/share/classes/java/nio/file/Path.java line 259:

> 257:      * characters, does not contain a dot, only the first character is a dot,
> 258:      * or the last character is a dot.
> 259:      *

Thanks for bringing this one back. The survey and the current proposal seems reasonable.

The spec will need cover the case that the Path doesn't have a file name (getFileName can return null so I assume the prototype implementation will NPE in that case). Are you planning to return null or the empty String for this case?

"file name string" needs to be replaced with "the String representation of the file name". This is significant aspect of the proposal in that it aligns the method with toString rather than other operations that preserve the platform representation of the path.

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

PR: https://git.openjdk.java.net/jdk/pull/2319