From bpb at openjdk.org  Wed Mar  1 00:35:38 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 1 Mar 2023 00:35:38 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers in
 PollingWatchService
Message-ID: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>

Modify `sun.nio.fs.PollingWatchService` to ignore any polling sensitivity modifiers as done by the other `WatchService`s.

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

Commit messages:
 - 8303413: (fs) Ignore polling interval sensitivity modifiers in PollingWatchService

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

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

From bpb at openjdk.org  Wed Mar  1 01:40:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 1 Mar 2023 01:40:15 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v18]
In-Reply-To: <zeqPFFObcVGQrMGMWcZfBfFbWf9H_LSskwcQOvD1x9I=.28fb1844-c14e-4b44-a409-711d41f7e595@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <zeqPFFObcVGQrMGMWcZfBfFbWf9H_LSskwcQOvD1x9I=.28fb1844-c14e-4b44-a409-711d41f7e595@github.com>
Message-ID: <mlEXMZ3Pqw0doGNhZqe2xV0tDCgGqHt3OigoWbuKAKE=.5e20ac0a-ed95-45a8-9d39-83fc21528b2a@github.com>

On Sat, 25 Feb 2023 13:29:52 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright

In the test classes `TransferTo` and `TransferTo2`, the methods `testNullPointerException` and `testStreamContents` are identical aside from expecting different `DataProvider`s. The contents of the methods could be abstracted out to common methods called by different `Test`s which expect different `DataProvider`s.

The test classes `TransferTo_2GB_transferFrom` and `TransferTo_2GB_transferTo` comprise roughly 120 lines of code each, but a diff of their contents reveals little in the way of substantive differences aside from jtreg tags, comments, and names:

96,99c95,97
<                 // performing actual transfer, effectively by multiple invocations of
<                 // FileChannel.transferFrom(ReadableByteChannel)
<                 try (InputStream inputStream = Channels.newInputStream(Channels.newChannel(
<                         new BufferedInputStream(Files.newInputStream(sourceFile))));
---
>                 // perform actual transfer, effectively by multiple invocations
>                 // of FileChannel.transferTo(WritableByteChannel)
>                 try (InputStream inputStream = Channels.newInputStream(FileChannel.open(sourceFile));

Perhaps something along these lines might work:
* rename `TransferToBase` to for example to `TransferBase` or `TransferFromToBase`;
* rename `TransferTo2` to `TransferFrom`;
* rename `TransferTo_2GB_transferX` classes to `TransferX_2GB`;
* refactor common code to `TransferBase` along the lines described above;
* refactor child classes as needed to use the common code.

Assuming the foregoing makes sense, there would remain a total of four tests. It might be possible also to merge `TransferFrom` and `TransferTo` into a single test, but I think the two tests `*_2GB*` should remain separate as they likely each have a sufficiently long run time.

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

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

From bpb at openjdk.org  Wed Mar  1 01:42:42 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 1 Mar 2023 01:42:42 GMT
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support position >
 size()
Message-ID: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>

Enhance `FileChannel::transferFrom` to extend the channel's file if `position > size()`. This is consistent with `FileChannel::write(ByteBuffer, long)`.

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

Commit messages:
 - 8303260: (fc) FileChannel::transferFrom should support position > size()

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

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

From alanb at openjdk.org  Wed Mar  1 08:13:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 1 Mar 2023 08:13:03 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers
 in PollingWatchService
In-Reply-To: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
Message-ID: <25cfs6RLymXR4076xcEJ8uvaY7tA2XtXLM38kQC8Mgk=.74fc676d-6a0b-4c0a-b207-de31b5ba674c@github.com>

On Wed, 1 Mar 2023 00:27:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `sun.nio.fs.PollingWatchService` to ignore any polling sensitivity modifiers as done by the other `WatchService`s.

Test change look okay but it will need a CSR and RN to track the behavior change. Also test/jdk/java/nio/file/WatchService/SensitivityModifier.java will need attention - maybe it should just be replaced with a sanity test that ensures that the register method does not throw when called with one of these modifiers.

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

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

From alanb at openjdk.org  Wed Mar  1 15:18:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 1 Mar 2023 15:18:29 GMT
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support
 position > size()
In-Reply-To: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
References: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
Message-ID: <x5w8_fH0-GXaM0eqUmf93KaEAlXpABr0JtNqAamFFKI=.f25ed45a-9378-44c7-8194-f81c312f72d9@github.com>

On Wed, 1 Mar 2023 01:34:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Enhance `FileChannel::transferFrom` to extend the channel's file if `position > size()`. This is consistent with `FileChannel::write(ByteBuffer, long)`.

The update to the API docs looks okay, the implementation change looks fine. I just wondering if there is anything that we might be missing to explain the restriction in the original API.

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

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

From bpb at openjdk.org  Wed Mar  1 16:34:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 1 Mar 2023 16:34:04 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers
 in PollingWatchService
In-Reply-To: <25cfs6RLymXR4076xcEJ8uvaY7tA2XtXLM38kQC8Mgk=.74fc676d-6a0b-4c0a-b207-de31b5ba674c@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
 <25cfs6RLymXR4076xcEJ8uvaY7tA2XtXLM38kQC8Mgk=.74fc676d-6a0b-4c0a-b207-de31b5ba674c@github.com>
Message-ID: <84b0ZEODps1G8na6xS8ksSZ60njgYdWEDYHkyTfF30E=.5a7291d5-0b2e-433a-b0f7-7552369c0670@github.com>

On Wed, 1 Mar 2023 08:09:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Also test/jdk/java/nio/file/WatchService/SensitivityModifier.java will need attention

I ran this test already and it still succeeds.

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

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

From alanb at openjdk.org  Wed Mar  1 16:44:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 1 Mar 2023 16:44:04 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers
 in PollingWatchService
In-Reply-To: <84b0ZEODps1G8na6xS8ksSZ60njgYdWEDYHkyTfF30E=.5a7291d5-0b2e-433a-b0f7-7552369c0670@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
 <25cfs6RLymXR4076xcEJ8uvaY7tA2XtXLM38kQC8Mgk=.74fc676d-6a0b-4c0a-b207-de31b5ba674c@github.com>
 <84b0ZEODps1G8na6xS8ksSZ60njgYdWEDYHkyTfF30E=.5a7291d5-0b2e-433a-b0f7-7552369c0670@github.com>
Message-ID: <91LKg6-SSUOPqU1cxte24ifHcYDJluIiv5pAE_Gw-lI=.e5cc4f54-2647-43a7-b870-2dca80ac8e97@github.com>

On Wed, 1 Mar 2023 16:30:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I ran this test already and it still succeeds.

I'm sure it does, but shouldn't it be replaced with some simple to just make sure that the modifiers are ignored? It is currently one of the slowest tests in the jdk_nio tree and with the changes here it overlaps with the existing WatchService tests.

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

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

From bpb at openjdk.org  Wed Mar  1 17:54:35 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 1 Mar 2023 17:54:35 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers
 in PollingWatchService [v2]
In-Reply-To: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
Message-ID: <wo3z_eoFTi7_Z3bQRMtFn1rDf85EpvorVuqhjYedbjs=.9000e730-e95a-429c-bd06-ef36a03dd2a7@github.com>

> Modify `sun.nio.fs.PollingWatchService` to ignore any polling sensitivity modifiers as done by the other `WatchService`s.

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

  8303413: Reduce SensitivityModifier test to ensuring no exception on register

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12795/files
  - new: https://git.openjdk.org/jdk/pull/12795/files/2ab63574..be2c1b4c

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

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

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

From alanb at openjdk.org  Thu Mar  2 08:35:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 Mar 2023 08:35:06 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers
 in PollingWatchService [v2]
In-Reply-To: <wo3z_eoFTi7_Z3bQRMtFn1rDf85EpvorVuqhjYedbjs=.9000e730-e95a-429c-bd06-ef36a03dd2a7@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
 <wo3z_eoFTi7_Z3bQRMtFn1rDf85EpvorVuqhjYedbjs=.9000e730-e95a-429c-bd06-ef36a03dd2a7@github.com>
Message-ID: <VplmbJx6jPxJtQtRK8cUJFbCNNlLbE0uUroEZOJ1aPI=.ccc1a851-e255-48f1-b3e4-1abce35d33ab@github.com>

On Wed, 1 Mar 2023 17:54:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `sun.nio.fs.PollingWatchService` to ignore any polling sensitivity modifiers as done by the other `WatchService`s.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303413: Reduce SensitivityModifier test to ensuring no exception on register

test/jdk/java/nio/file/WatchService/SensitivityModifier.java line 96:

> 94:             // register the directories (random sensitivity)
> 95:             register(dirs, watcher);
> 96: 

I assume there is a lot more that is no longer needed in this test, e.g most of doTest is not needed, POLL_TIMEOUT_SECONDS can be removed, ...  I suspect the resulting test will be very simple - just test that the temp dir can be registered with each of the sensitivity levels.

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

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

From michaelo at apache.org  Thu Mar  2 10:51:55 2023
From: michaelo at apache.org (Michael Osipov)
Date: Thu, 2 Mar 2023 11:51:55 +0100
Subject: ATOMIC_MOVE fails under high frequency conditions on Windows
In-Reply-To: <CAOdYfZU7ZDr9sSO3y1jFCRWrYLeqzkeBxZ-0HBNyKihpgfq-9A@mail.gmail.com>
References: <0f99feeb-3508-8853-730c-f9870ebe62af@apache.org>
 <CAOdYfZU7ZDr9sSO3y1jFCRWrYLeqzkeBxZ-0HBNyKihpgfq-9A@mail.gmail.com>
Message-ID: <e9323925-4ae3-f213-f11f-7fe9859c83d3@apache.org>

Am 2023-02-27 um 17:56 schrieb Robert Muir:
> On Sun, Feb 26, 2023 at 3:37?PM Michael Osipov <michaelo at apache.org> wrote:
>> The MoveFileEx does not properly block until the operation completes and
>> some Windows-internal locking fails the operation. Even the
>> While investigating the problem, it seems to be very common on Windows
>> with Jenkins, Kafka, etc. but also Python folks discussed the issue
>> (https://github.com/python/cpython/issues/53074).
>> Now, if I apply the following patch:
>>> -                Files.move( tempFile, file, StandardCopyOption.ATOMIC_MOVE );
>>> +                Kernel32.INSTANCE.MoveFileEx( tempFile.toAbsolutePath().toString(), file.toAbsolutePath().toString(),
>>> +                    new DWORD( WinBase.MOVEFILE_REPLACE_EXISTING | WinBase.MOVEFILE_WRITE_THROUGH ) );
>>
>> It just works. MOVEFILE_WRITE_THROUGH guarantees the operaton to block
>> until it is completed.
> 
> Hi, we rely on this as well in apache lucene, and have some gnarly
> tests around it, but we haven't seen this specific issue.
> Maybe we dodge it because we always fsync() files before renaming
> them? I don't see any synchronization to disk in your sample code.

No, we haven't used fsync() so far, this collocated file stuff is pretty 
new. We simply didn't expect this and never had such issues.

Can you guide me to the code spots in Lucene for the optimal behavior?

M

From rcmuir at gmail.com  Thu Mar  2 13:07:24 2023
From: rcmuir at gmail.com (Robert Muir)
Date: Thu, 2 Mar 2023 08:07:24 -0500
Subject: ATOMIC_MOVE fails under high frequency conditions on Windows
In-Reply-To: <e9323925-4ae3-f213-f11f-7fe9859c83d3@apache.org>
References: <0f99feeb-3508-8853-730c-f9870ebe62af@apache.org>
 <CAOdYfZU7ZDr9sSO3y1jFCRWrYLeqzkeBxZ-0HBNyKihpgfq-9A@mail.gmail.com>
 <e9323925-4ae3-f213-f11f-7fe9859c83d3@apache.org>
Message-ID: <CAOdYfZXeKepfZMeuf2j=CbW_q1FjU_Ur1co+Db8RVSy5zqyLOw@mail.gmail.com>

On Thu, Mar 2, 2023 at 5:52?AM Michael Osipov <michaelo at apache.org> wrote:
>
> Can you guide me to the code spots in Lucene for the optimal behavior?
>

You just want to look into FileChannel.force().

Here is the helper method we use:
https://github.com/apache/lucene/blob/70c152bf321f20c589f1e002fa01ccbfc74aa398/lucene/core/src/java/org/apache/lucene/util/IOUtils.java#L408-L444

From bpb at openjdk.org  Thu Mar  2 16:51:38 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 2 Mar 2023 16:51:38 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers
 in PollingWatchService [v3]
In-Reply-To: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
Message-ID: <spqxr_y2uxzhNTes30p2yOvvOBQ9VpOP8BqfvbfHNsg=.c2ef7bf1-1c80-489a-ab0d-306045f32afb@github.com>

> Modify `sun.nio.fs.PollingWatchService` to ignore any polling sensitivity modifiers as done by the other `WatchService`s.

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

  8303413: Simplify SensitivityModifier test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12795/files
  - new: https://git.openjdk.org/jdk/pull/12795/files/be2c1b4c..2e9867bd

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

  Stats: 41 lines in 1 file changed: 3 ins; 25 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12795.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12795/head:pull/12795

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

From bpb at openjdk.org  Thu Mar  2 16:54:27 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 2 Mar 2023 16:54:27 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers
 in PollingWatchService [v3]
In-Reply-To: <VplmbJx6jPxJtQtRK8cUJFbCNNlLbE0uUroEZOJ1aPI=.ccc1a851-e255-48f1-b3e4-1abce35d33ab@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
 <wo3z_eoFTi7_Z3bQRMtFn1rDf85EpvorVuqhjYedbjs=.9000e730-e95a-429c-bd06-ef36a03dd2a7@github.com>
 <VplmbJx6jPxJtQtRK8cUJFbCNNlLbE0uUroEZOJ1aPI=.ccc1a851-e255-48f1-b3e4-1abce35d33ab@github.com>
Message-ID: <dcwH990JTMJi7K_-xoMxLJvj-YXGW_3L65nZufMbfpw=.61c8ce25-5c6f-498c-aee4-3b1e7fdcca7f@github.com>

On Thu, 2 Mar 2023 08:32:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303413: Simplify SensitivityModifier test
>
> test/jdk/java/nio/file/WatchService/SensitivityModifier.java line 96:
> 
>> 94:             // register the directories (random sensitivity)
>> 95:             register(dirs, watcher);
>> 96: 
> 
> I assume there is a lot more that is no longer needed in this test, e.g most of doTest is not needed, POLL_TIMEOUT_SECONDS can be removed, ...  I suspect the resulting test will be very simple - just test that the temp dir can be registered with each of the sensitivity levels.

Fixed (enough?) in 2e9867bd45cfbad727699a1254514227b995dd7a.

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

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

From alanb at openjdk.org  Thu Mar  2 19:39:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 Mar 2023 19:39:24 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers
 in PollingWatchService [v3]
In-Reply-To: <spqxr_y2uxzhNTes30p2yOvvOBQ9VpOP8BqfvbfHNsg=.c2ef7bf1-1c80-489a-ab0d-306045f32afb@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
 <spqxr_y2uxzhNTes30p2yOvvOBQ9VpOP8BqfvbfHNsg=.c2ef7bf1-1c80-489a-ab0d-306045f32afb@github.com>
Message-ID: <O7fY7Y231uKIaYDNcySQvHwv1BY6ChL9_0LmKwet_Xg=.a34d7375-aadf-4267-9fae-2ea7afd7f792@github.com>

On Thu, 2 Mar 2023 16:51:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `sun.nio.fs.PollingWatchService` to ignore any polling sensitivity modifiers as done by the other `WatchService`s.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303413: Simplify SensitivityModifier test

Updated version looks fine. In this case, I'd probably update the @bug line to add 8303413, only because the test is very different to the original test.

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

Marked as reviewed by alanb (Reviewer).

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

From bpb at openjdk.org  Thu Mar  2 20:07:58 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 2 Mar 2023 20:07:58 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers
 in PollingWatchService [v4]
In-Reply-To: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
Message-ID: <IPL2r-C6HlWihTy-MnSxyaCbuS4A1oTKKi7ZMtruFBQ=.902b9e9e-ab51-4cd9-9855-b1a2bb115a89@github.com>

> Modify `sun.nio.fs.PollingWatchService` to ignore any polling sensitivity modifiers as done by the other `WatchService`s.

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

  8303413: Add 8303413 to @bug tag in SensitivityModifier test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12795/files
  - new: https://git.openjdk.org/jdk/pull/12795/files/2e9867bd..a2216a72

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

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

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

From bpb at openjdk.org  Thu Mar  2 20:08:01 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 2 Mar 2023 20:08:01 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers
 in PollingWatchService [v3]
In-Reply-To: <O7fY7Y231uKIaYDNcySQvHwv1BY6ChL9_0LmKwet_Xg=.a34d7375-aadf-4267-9fae-2ea7afd7f792@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
 <spqxr_y2uxzhNTes30p2yOvvOBQ9VpOP8BqfvbfHNsg=.c2ef7bf1-1c80-489a-ab0d-306045f32afb@github.com>
 <O7fY7Y231uKIaYDNcySQvHwv1BY6ChL9_0LmKwet_Xg=.a34d7375-aadf-4267-9fae-2ea7afd7f792@github.com>
Message-ID: <8O0oZyFuL2SQ_XLv9AWcaR9P7hWPzTSvSbG4Asu-Hq0=.aaf546bd-57ba-48e5-a6c0-b986aeb6957b@github.com>

On Thu, 2 Mar 2023 19:36:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'd probably update the @bug line to add 8303413

Done in a2216a728b642a649c4c6261cd8ed1b1bc18136a.

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

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

From alanb at openjdk.org  Fri Mar  3 07:11:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 Mar 2023 07:11:17 GMT
Subject: RFR: 8303413: (fs) Ignore polling interval sensitivity modifiers
 in PollingWatchService [v4]
In-Reply-To: <IPL2r-C6HlWihTy-MnSxyaCbuS4A1oTKKi7ZMtruFBQ=.902b9e9e-ab51-4cd9-9855-b1a2bb115a89@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
 <IPL2r-C6HlWihTy-MnSxyaCbuS4A1oTKKi7ZMtruFBQ=.902b9e9e-ab51-4cd9-9855-b1a2bb115a89@github.com>
Message-ID: <fAIuUFGKbSqokiPXAvafokZtq7jKx76Q0-Ffq09aJNg=.f1c8912f-e0f5-4634-80c5-af4dee995db4@github.com>

On Thu, 2 Mar 2023 20:07:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `sun.nio.fs.PollingWatchService` to ignore any polling sensitivity modifiers as done by the other `WatchService`s.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303413: Add 8303413 to @bug tag in SensitivityModifier test

Marked as reviewed by alanb (Reviewer).

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

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

From bpb at openjdk.org  Fri Mar  3 18:37:27 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 3 Mar 2023 18:37:27 GMT
Subject: Integrated: 8303413: (fs) Ignore polling interval sensitivity
 modifiers in PollingWatchService
In-Reply-To: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
References: <o1VLjWGzSez1GugCDr0TkSfFVB81DgVyxHjpYBWNhpY=.04747b93-c890-4bb0-baa5-ba1b8307eff8@github.com>
Message-ID: <BCjQWt0Re8SSHgrNuTW4pGgeYQj6_1vaGIaYCKrujZ0=.b0e3d8f5-fa01-4267-a8a7-c9952ac35bc9@github.com>

On Wed, 1 Mar 2023 00:27:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `sun.nio.fs.PollingWatchService` to ignore any polling sensitivity modifiers as done by the other `WatchService`s.

This pull request has now been integrated.

Changeset: a04b1049
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a04b1049ffc29c2ab2ec1b39e70b72288a39b371
Stats:     110 lines in 2 files changed: 3 ins; 79 del; 28 mod

8303413: (fs) Ignore polling interval sensitivity modifiers in PollingWatchService

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Sun Mar  5 19:24:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 5 Mar 2023 19:24:02 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
Message-ID: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>

This is a small update to the underlying implementation of Socket.setTrafficClass so that it attempts to set the IP_TOS socket option when the socket is IPv6 and the operating system allows this option to be set on IPv6 sockets. The change is deliberately limited to the SocketImpl and SocketChannel implementation to avoid impacting DatagramChannel.

Socket.setTrafficClass is specified as a hint. For TCP connections it is possible on some platforms to set IP_TOS on an unbound socket to the ToS value to use in the SYN packet when establishing a connection. Setting it after a connection is established is possible on some platforms too. The JDK uses IPv6 sockets since JDK 1.4 so it gets a bit more complicated due to patchy support for IP_TOS.

- Linux allows IP_TOS to be set on an IPv6 socket at any time. If set on an unbound socket then the ToS will have the expected value when establishing a connection and it can be changed any time after connecting.
- macOS doesn't allow IP_TOS to be set on an IPv6 socket and it doesn't use the IPV6_TCLASS value as the IPv4 ToS. So on macOS, you have to use an IPv4 socket and set IP_TOS before connecting the socket.
- Windows hasn't allowed applications change the ToS for a long time. It allows the IP_TOS to be set on an unbound IPv6 socket but the value is not used.

The bug report report is Socket.setTrafficClass hasn't worked on Linux since JDK 13 when the SocketImpl was replaced. The workaround is to run with-Djava.net.preferIPv4=true. 

The proposed change is to just attempt to set both IPV6_TCLASS and IP_TOS when the socket is IPv6 and the operating system allows IPPROTO level sockets to be setup on IPv6 sockets. At some point I'd like to replace the underlying socket options implementation as it no longer needs to be in libnet, and that would be the limit to re-visit the equivalent in the channel implementations.

I had to use tcpdump and strace to test the changes, I don't think it's possible to create an automated test for this change.

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

Commit messages:
 - Extend to SocketChannel socket adaptor
 - Initial commit

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

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

From duke at openjdk.org  Sun Mar  5 21:09:11 2023
From: duke at openjdk.org (altrisi)
Date: Sun, 5 Mar 2023 21:09:11 GMT
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support
 position > size()
In-Reply-To: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
References: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
Message-ID: <pRdb-ocGRTsX2-tUOV7Kr61k4_XP4n-ERx7w2Jb6zHA=.23331916-d798-47d1-af1c-aebbec4f0437@github.com>

On Wed, 1 Mar 2023 01:34:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Enhance `FileChannel::transferFrom` to extend the channel's file if `position > size()`. This is consistent with `FileChannel::write(ByteBuffer, long)`.

Unrelated to the content of this PR, but the bot seems to be obsessed with editing the main comment description, at the time of writing it has made 4852 edits, seems to make around one per minute. Thought I'd mention it given it's easy to miss so I figured this way it's more likely to get resolved.

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

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

From djelinski at openjdk.org  Mon Mar  6 09:14:12 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 6 Mar 2023 09:14:12 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
In-Reply-To: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
References: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
Message-ID: <ax6C-wl4KetTxAY6hBvI1AP2-05MLD5bTuNo-6dJ-iI=.0068baf0-772d-40b8-8b6b-bb28713bfb85@github.com>

On Sun, 5 Mar 2023 09:33:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a small update to the underlying implementation of Socket.setTrafficClass so that it attempts to set the IP_TOS socket option when the socket is IPv6 and the operating system allows this option to be set on IPv6 sockets. The change is deliberately limited to the SocketImpl and SocketChannel implementation to avoid impacting DatagramChannel.
> 
> Socket.setTrafficClass is specified as a hint. For TCP connections it is possible on some platforms to set IP_TOS on an unbound socket to the ToS value to use in the SYN packet when establishing a connection. Setting it after a connection is established is possible on some platforms too. The JDK uses IPv6 sockets since JDK 1.4 so it gets a bit more complicated due to patchy support for IP_TOS.
> 
> - Linux allows IP_TOS to be set on an IPv6 socket at any time. If set on an unbound socket then the ToS will have the expected value when establishing a connection and it can be changed any time after connecting.
> - macOS doesn't allow IP_TOS to be set on an IPv6 socket and it doesn't use the IPV6_TCLASS value as the IPv4 ToS. So on macOS, you have to use an IPv4 socket and set IP_TOS before connecting the socket.
> - Windows hasn't allowed applications change the ToS for a long time. It allows the IP_TOS to be set on an unbound IPv6 socket but the value is not used.
> 
> The bug report report is Socket.setTrafficClass hasn't worked on Linux since JDK 13 when the SocketImpl was replaced. The workaround is to run with-Djava.net.preferIPv4=true. 
> 
> The proposed change is to just attempt to set both IPV6_TCLASS and IP_TOS when the socket is IPv6 and the operating system allows IPPROTO level sockets to be setup on IPv6 sockets. At some point I'd like to replace the underlying socket options implementation as it no longer needs to be in libnet, and that would be the limit to re-visit the equivalent in the channel implementations.
> 
> I had to use tcpdump and strace to test the changes, I don't think it's possible to create an automated test for this change.

LGTM.

Have you considered merging the new `setIpSocketOption` with the existing `DatagramChannelImpl.setOption`?

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

Marked as reviewed by djelinski (Committer).

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

From alanb at openjdk.org  Mon Mar  6 09:53:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Mar 2023 09:53:14 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
In-Reply-To: <ax6C-wl4KetTxAY6hBvI1AP2-05MLD5bTuNo-6dJ-iI=.0068baf0-772d-40b8-8b6b-bb28713bfb85@github.com>
References: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
 <ax6C-wl4KetTxAY6hBvI1AP2-05MLD5bTuNo-6dJ-iI=.0068baf0-772d-40b8-8b6b-bb28713bfb85@github.com>
Message-ID: <D8cRjzrRDTHkUhAWvJwUA4wPjOm_0YemWWQ46Q1J7z4=.f024801a-e65d-4b85-b78a-fc0f5155c070@github.com>

On Mon, 6 Mar 2023 09:11:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Have you considered merging the new `setIpSocketOption` with the existing `DatagramChannelImpl.setOption`?

Yes, but not for this PR because there is a larger piece of work required here to get rid of a lot of cruft related to socket options.

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

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

From duke at openjdk.org  Mon Mar  6 15:26:15 2023
From: duke at openjdk.org (JackyWoo)
Date: Mon, 6 Mar 2023 15:26:15 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
Message-ID: <ShHpGf8u5wgsB_CZLGxys5dF4eF18j-UiMqBnXqhuQc=.df882174-b36e-4cce-ac50-12a6c7dfd75b@github.com>

This pr try to fix [JDK-8303509](https://bugs.openjdk.org/browse/JDK-8303509): Socket setTrafficClass does not work for IPv4 connections when IPv6 enabled.

### Change Log
When setting traffic class with IPv6 enabled, also set to IPv4 family.

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

Commit messages:
 - add some comments
 - 8303509:fix setTrafficClass not work when IPv6 enabled

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

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

From kcr at openjdk.org  Mon Mar  6 15:26:15 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 6 Mar 2023 15:26:15 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
In-Reply-To: <ShHpGf8u5wgsB_CZLGxys5dF4eF18j-UiMqBnXqhuQc=.df882174-b36e-4cce-ac50-12a6c7dfd75b@github.com>
References: <ShHpGf8u5wgsB_CZLGxys5dF4eF18j-UiMqBnXqhuQc=.df882174-b36e-4cce-ac50-12a6c7dfd75b@github.com>
Message-ID: <qrHxJu18TDy8dn7-FNjVpm5x8iAJ3tOqU4lHykxd7BA=.24bc05f9-f8a9-4f15-84b6-2e2146805ddc@github.com>

On Fri, 3 Mar 2023 10:36:45 GMT, JackyWoo <duke at openjdk.org> wrote:

> This pr try to fix [JDK-8303509](https://bugs.openjdk.org/browse/JDK-8303509): Socket setTrafficClass does not work for IPv4 connections when IPv6 enabled.
> 
> ### Change Log
> When setting traffic class with IPv6 enabled, also set to IPv4 family.

You will need to change the title of your PR, which you might as well do while waiting for your OCA to be confirmed. First, add a space after the "8303509:". Second, change the rest of it to _exactly_ match the title of the bug, meaning do not use the word "fix" in the title, nor use back-ticks for code style. Putting that all together, the title should be exactly the following:

8303509: Socket setTrafficClass does not work for IPv4 connections when IPv6 enabled

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

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

From alanb at openjdk.org  Mon Mar  6 15:52:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Mar 2023 15:52:37 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
In-Reply-To: <ShHpGf8u5wgsB_CZLGxys5dF4eF18j-UiMqBnXqhuQc=.df882174-b36e-4cce-ac50-12a6c7dfd75b@github.com>
References: <ShHpGf8u5wgsB_CZLGxys5dF4eF18j-UiMqBnXqhuQc=.df882174-b36e-4cce-ac50-12a6c7dfd75b@github.com>
Message-ID: <7XHeHM7NpxwkYtFsB-m1x-T4_X2VF1k56h9kLzaeKkI=.0b2143f4-74df-47ca-810c-164e46298158@github.com>

On Fri, 3 Mar 2023 10:36:45 GMT, JackyWoo <duke at openjdk.org> wrote:

> This pr try to fix [JDK-8303509](https://bugs.openjdk.org/browse/JDK-8303509): Socket setTrafficClass does not work for IPv4 connections when IPv6 enabled.
> 
> ### Change Log
> When setting traffic class with IPv6 enabled, also set to IPv4 family.

[PR 12872](https://github.com/openjdk/jdk/pull/12872) is already under review for this issue.

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

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

From michaelm at openjdk.org  Mon Mar  6 16:08:23 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 6 Mar 2023 16:08:23 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
In-Reply-To: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
References: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
Message-ID: <uiD2JDlGWoRRqLhlhKpnA7EPWwcObXrdnWBsGPQWJKk=.97c7a790-b98e-4a2e-b314-733530bf7438@github.com>

On Sun, 5 Mar 2023 09:33:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a small update to the underlying implementation of Socket.setTrafficClass so that it attempts to set the IP_TOS socket option when the socket is IPv6 and the operating system allows this option to be set on IPv6 sockets. The change is deliberately limited to the SocketImpl and SocketChannel implementation to avoid impacting DatagramChannel.
> 
> Socket.setTrafficClass is specified as a hint. For TCP connections it is possible on some platforms to set IP_TOS on an unbound socket to the ToS value to use in the SYN packet when establishing a connection. Setting it after a connection is established is possible on some platforms too. The JDK uses IPv6 sockets since JDK 1.4 so it gets a bit more complicated due to patchy support for IP_TOS.
> 
> - Linux allows IP_TOS to be set on an IPv6 socket at any time. If set on an unbound socket then the ToS will have the expected value when establishing a connection and it can be changed any time after connecting.
> - macOS doesn't allow IP_TOS to be set on an IPv6 socket and it doesn't use the IPV6_TCLASS value as the IPv4 ToS. So on macOS, you have to use an IPv4 socket and set IP_TOS before connecting the socket.
> - Windows hasn't allowed applications change the ToS for a long time. It allows the IP_TOS to be set on an unbound IPv6 socket but the value is not used.
> 
> The bug report report is Socket.setTrafficClass hasn't worked on Linux since JDK 13 when the SocketImpl was replaced. The workaround is to run with-Djava.net.preferIPv4=true. 
> 
> The proposed change is to just attempt to set both IPV6_TCLASS and IP_TOS when the socket is IPv6 and the operating system allows IPPROTO level sockets to be setup on IPv6 sockets. At some point I'd like to replace the underlying socket options implementation as it no longer needs to be in libnet, and that would be the limit to re-visit the equivalent in the channel implementations.
> 
> I had to use tcpdump and strace to test the changes, I don't think it's possible to create an automated test for this change.

src/java.base/share/classes/sun/nio/ch/Net.java line 104:

> 102:      * need to be set so that the settings are effective for IPv4 connections
> 103:      * and datagrams.
> 104:      */

There is a similar reference to multicast in the native implementations (windows and unix) of shouldSetBothIPv4AndIPv6Options0(). Maybe, the same comment change should be there too.

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

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

From michaelm at openjdk.org  Mon Mar  6 16:33:07 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 6 Mar 2023 16:33:07 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
In-Reply-To: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
References: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
Message-ID: <rXZZJpqWegSF8wJwN6DIHPeBuIz8zAXbvEjz-KdMaUs=.747db1a9-277f-4a15-8a69-29ef1dafeed9@github.com>

On Sun, 5 Mar 2023 09:33:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a small update to the underlying implementation of Socket.setTrafficClass so that it attempts to set the IP_TOS socket option when the socket is IPv6 and the operating system allows this option to be set on IPv6 sockets. The change is deliberately limited to the SocketImpl and SocketChannel implementation to avoid impacting DatagramChannel.
> 
> Socket.setTrafficClass is specified as a hint. For TCP connections it is possible on some platforms to set IP_TOS on an unbound socket to the ToS value to use in the SYN packet when establishing a connection. Setting it after a connection is established is possible on some platforms too. The JDK uses IPv6 sockets since JDK 1.4 so it gets a bit more complicated due to patchy support for IP_TOS.
> 
> - Linux allows IP_TOS to be set on an IPv6 socket at any time. If set on an unbound socket then the ToS will have the expected value when establishing a connection and it can be changed any time after connecting.
> - macOS doesn't allow IP_TOS to be set on an IPv6 socket and it doesn't use the IPV6_TCLASS value as the IPv4 ToS. So on macOS, you have to use an IPv4 socket and set IP_TOS before connecting the socket.
> - Windows hasn't allowed applications change the ToS for a long time. It allows the IP_TOS to be set on an unbound IPv6 socket but the value is not used.
> 
> The bug report report is Socket.setTrafficClass hasn't worked on Linux since JDK 13 when the SocketImpl was replaced. The workaround is to run with-Djava.net.preferIPv4=true. 
> 
> The proposed change is to just attempt to set both IPV6_TCLASS and IP_TOS when the socket is IPv6 and the operating system allows IPPROTO level sockets to be setup on IPv6 sockets. At some point I'd like to replace the underlying socket options implementation as it no longer needs to be in libnet, and that would be the limit to re-visit the equivalent in the channel implementations.
> 
> I had to use tcpdump and strace to test the changes, I don't think it's possible to create an automated test for this change.

The change looks fine (with or without comment suggestion)

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

Marked as reviewed by michaelm (Reviewer).

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

From alanb at openjdk.org  Mon Mar  6 17:17:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Mar 2023 17:17:47 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled [v2]
In-Reply-To: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
References: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
Message-ID: <K3uOG_rQ0ySvkkN6dkG-TaTd1633UIDf8LFur4PXEtU=.aed6c524-dc2e-4381-b887-1f8152eae48d@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
> This is a small update to the underlying implementation of Socket.setTrafficClass so that it attempts to set the IP_TOS socket option when the socket is IPv6 and the operating system allows this option to be set on IPv6 sockets. The change is deliberately limited to the SocketImpl and SocketChannel implementation to avoid impacting DatagramChannel.
> 
> Socket.setTrafficClass is specified as a hint. For TCP connections it is possible on some platforms to set IP_TOS on an unbound socket to the ToS value to use in the SYN packet when establishing a connection. Setting it after a connection is established is possible on some platforms too. The JDK uses IPv6 sockets since JDK 1.4 so it gets a bit more complicated due to patchy support for IP_TOS.
> 
> - Linux allows IP_TOS to be set on an IPv6 socket at any time. If set on an unbound socket then the ToS will have the expected value when establishing a connection and it can be changed any time after connecting.
> - macOS doesn't allow IP_TOS to be set on an IPv6 socket and it doesn't use the IPV6_TCLASS value as the IPv4 ToS. So on macOS, you have to use an IPv4 socket and set IP_TOS before connecting the socket.
> - Windows hasn't allowed applications change the ToS for a long time. It allows the IP_TOS to be set on an unbound IPv6 socket but the value is not used.
> 
> The bug report report is Socket.setTrafficClass hasn't worked on Linux since JDK 13 when the SocketImpl was replaced. The workaround is to run with-Djava.net.preferIPv4=true. 
> 
> The proposed change is to just attempt to set both IPV6_TCLASS and IP_TOS when the socket is IPv6 and the operating system allows IPPROTO level sockets to be setup on IPv6 sockets. At some point I'd like to replace the underlying socket options implementation as it no longer needs to be in libnet, and that would be the limit to re-visit the equivalent in the channel implementations.
> 
> I had to use tcpdump and strace to test the changes, I don't think it's possible to create an automated test for this change.

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

 - Update Net.shouldSetBothIPv4AndIPv6Options0 comments
 - Merge
 - Extend to SocketChannel socket adaptor
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12872/files
  - new: https://git.openjdk.org/jdk/pull/12872/files/c6766a4d..fd89b8f0

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

  Stats: 3935 lines in 82 files changed: 2177 ins; 1099 del; 659 mod
  Patch: https://git.openjdk.org/jdk/pull/12872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12872/head:pull/12872

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

From alanb at openjdk.org  Mon Mar  6 17:17:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Mar 2023 17:17:50 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled [v2]
In-Reply-To: <uiD2JDlGWoRRqLhlhKpnA7EPWwcObXrdnWBsGPQWJKk=.97c7a790-b98e-4a2e-b314-733530bf7438@github.com>
References: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
 <uiD2JDlGWoRRqLhlhKpnA7EPWwcObXrdnWBsGPQWJKk=.97c7a790-b98e-4a2e-b314-733530bf7438@github.com>
Message-ID: <p9mL0LMDMD34Bwwtvtkpcl6bchy2eKV4iylzy-KCeII=.d77b2e7e-6dcb-4357-80b1-dca648c59425@github.com>

On Mon, 6 Mar 2023 16:05:07 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Update Net.shouldSetBothIPv4AndIPv6Options0 comments
>>  - Merge
>>  - Extend to SocketChannel socket adaptor
>>  - Initial commit
>
> src/java.base/share/classes/sun/nio/ch/Net.java line 104:
> 
>> 102:      * need to be set so that the settings are effective for IPv4 connections
>> 103:      * and datagrams.
>> 104:      */
> 
> There is a similar reference to multicast in the native implementations (windows and unix) of shouldSetBothIPv4AndIPv6Options0(). Maybe, the same comment change should be there too.

Good point, the comments in the native code should be aligned with the method description.

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

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

From duke at openjdk.org  Wed Mar  8 06:40:14 2023
From: duke at openjdk.org (JackyWoo)
Date: Wed, 8 Mar 2023 06:40:14 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
In-Reply-To: <7XHeHM7NpxwkYtFsB-m1x-T4_X2VF1k56h9kLzaeKkI=.0b2143f4-74df-47ca-810c-164e46298158@github.com>
References: <ShHpGf8u5wgsB_CZLGxys5dF4eF18j-UiMqBnXqhuQc=.df882174-b36e-4cce-ac50-12a6c7dfd75b@github.com>
 <7XHeHM7NpxwkYtFsB-m1x-T4_X2VF1k56h9kLzaeKkI=.0b2143f4-74df-47ca-810c-164e46298158@github.com>
Message-ID: <Sus121jVXD5Y6UoLqLioMhW5p9UET_7TLuWBoqIy0jo=.0f2c19c2-0756-496a-93eb-ac7aee85a058@github.com>

On Mon, 6 Mar 2023 15:49:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This pr try to fix [JDK-8303509](https://bugs.openjdk.org/browse/JDK-8303509): Socket setTrafficClass does not work for IPv4 connections when IPv6 enabled.
>> 
>> ### Change Log
>> When setting traffic class with IPv6 enabled, also set to IPv4 family.
>
> [PR 12872](https://github.com/openjdk/jdk/pull/12872) is already under review for this issue.

@AlanBateman I encountered the problem in my production environment, so I reported the bug.  

Thanks for your fix. And I will close my PR.

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

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

From duke at openjdk.org  Wed Mar  8 06:40:16 2023
From: duke at openjdk.org (JackyWoo)
Date: Wed, 8 Mar 2023 06:40:16 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
In-Reply-To: <qrHxJu18TDy8dn7-FNjVpm5x8iAJ3tOqU4lHykxd7BA=.24bc05f9-f8a9-4f15-84b6-2e2146805ddc@github.com>
References: <ShHpGf8u5wgsB_CZLGxys5dF4eF18j-UiMqBnXqhuQc=.df882174-b36e-4cce-ac50-12a6c7dfd75b@github.com>
 <qrHxJu18TDy8dn7-FNjVpm5x8iAJ3tOqU4lHykxd7BA=.24bc05f9-f8a9-4f15-84b6-2e2146805ddc@github.com>
Message-ID: <IbU8xBKzNcnapTzoQYGdVnDLgOvA7wW5FnuaOAomSFc=.6743a056-597f-4314-b051-c5b8bae80c70@github.com>

On Fri, 3 Mar 2023 11:56:20 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This pr try to fix [JDK-8303509](https://bugs.openjdk.org/browse/JDK-8303509): Socket setTrafficClass does not work for IPv4 connections when IPv6 enabled.
>> 
>> ### Change Log
>> When setting traffic class with IPv6 enabled, also set to IPv4 family.
>
> You will need to change the title of your PR, which you might as well do while waiting for your OCA to be confirmed. First, add a space after the "8303509:". Second, change the rest of it to _exactly_ match the title of the bug, meaning do not use the word "fix" in the title, nor use back-ticks for code style. Putting that all together, the title should be exactly the following:
> 
> 8303509: Socket setTrafficClass does not work for IPv4 connections when IPv6 enabled

@kevinrushforth Thanks for you help to my first open JDK PR.

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

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

From michaelm at openjdk.org  Wed Mar  8 10:53:09 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 8 Mar 2023 10:53:09 GMT
Subject: RFR: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled [v2]
In-Reply-To: <K3uOG_rQ0ySvkkN6dkG-TaTd1633UIDf8LFur4PXEtU=.aed6c524-dc2e-4381-b887-1f8152eae48d@github.com>
References: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
 <K3uOG_rQ0ySvkkN6dkG-TaTd1633UIDf8LFur4PXEtU=.aed6c524-dc2e-4381-b887-1f8152eae48d@github.com>
Message-ID: <RXR5PQ4b0yGJn9Tb_kXxyAkafkmTiEsMlY2Gf8l2o8o=.faec0eb9-1f44-4722-8cfc-88547cdf9083@github.com>

On Mon, 6 Mar 2023 17:17:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is a small update to the underlying implementation of Socket.setTrafficClass so that it attempts to set the IP_TOS socket option when the socket is IPv6 and the operating system allows this option to be set on IPv6 sockets. The change is deliberately limited to the SocketImpl and SocketChannel implementation to avoid impacting DatagramChannel.
>> 
>> Socket.setTrafficClass is specified as a hint. For TCP connections it is possible on some platforms to set IP_TOS on an unbound socket to the ToS value to use in the SYN packet when establishing a connection. Setting it after a connection is established is possible on some platforms too. The JDK uses IPv6 sockets since JDK 1.4 so it gets a bit more complicated due to patchy support for IP_TOS.
>> 
>> - Linux allows IP_TOS to be set on an IPv6 socket at any time. If set on an unbound socket then the ToS will have the expected value when establishing a connection and it can be changed any time after connecting.
>> - macOS doesn't allow IP_TOS to be set on an IPv6 socket and it doesn't use the IPV6_TCLASS value as the IPv4 ToS. So on macOS, you have to use an IPv4 socket and set IP_TOS before connecting the socket.
>> - Windows hasn't allowed applications change the ToS for a long time. It allows the IP_TOS to be set on an unbound IPv6 socket but the value is not used.
>> 
>> The bug report report is Socket.setTrafficClass hasn't worked on Linux since JDK 13 when the SocketImpl was replaced. The workaround is to run with-Djava.net.preferIPv4=true. 
>> 
>> The proposed change is to just attempt to set both IPV6_TCLASS and IP_TOS when the socket is IPv6 and the operating system allows IPPROTO level sockets to be setup on IPv6 sockets. At some point I'd like to replace the underlying socket options implementation as it no longer needs to be in libnet, and that would be the limit to re-visit the equivalent in the channel implementations.
>> 
>> I had to use tcpdump and strace to test the changes, I don't think it's possible to create an automated test for this change.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Update Net.shouldSetBothIPv4AndIPv6Options0 comments
>  - Merge
>  - Extend to SocketChannel socket adaptor
>  - Initial commit

Comment change looks good.

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

Marked as reviewed by michaelm (Reviewer).

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

From mike at hydraulic.software  Wed Mar  8 10:14:36 2023
From: mike at hydraulic.software (Mike Hearn)
Date: Wed, 8 Mar 2023 11:14:36 +0100
Subject: UNIX domain sockets bug on Windows
In-Reply-To: <247b5106-9d23-fc84-e602-ec0e75a5e2ca@oracle.com>
References: <CAGv+2bNfkcq1X_kHgahq=peMKwmZ2QtRaHf-2xTXFMxXwb1xuQ@mail.gmail.com>
 <57459407-d234-1be3-94e0-8b52826f1e86@oracle.com>
 <CAGv+2bNwg02ZCUVhDd199dDZehgqXO+c1S75BhEY_caTnGTQBQ@mail.gmail.com>
 <247b5106-9d23-fc84-e602-ec0e75a5e2ca@oracle.com>
Message-ID: <CAGv+2bOPuE2v92BmNqi=hGjiUuCoTEs7OX31yRa-N=ZZ8-X0JQ@mail.gmail.com>

Unfortunately I need to resurrect this thread. Although in November we
worked around the issue by patching the JVM we ship with our
applications, now the apps being shipped by one of our customers are
hitting the exact same thing. Obviously telling them to make their own
JVM builds with patches is not a workable solution here, nor really
for anyone else.

Here's what we know:

1. The problem occurs only on some machines but not others (but the
machines affected are affected reliably).

2. For unclear reasons on those machines the problem only occurs if
the app is installed using an MSIX package (the type used by the
Windows Store). If the app is run from an ordinary zip, network
connections function correctly. This is probably why you find it hard
to reproduce. I can supply such an app if it would help with testing.

3. We don't think it's security software related because the affected
machines don't use any beyond the built-in Windows Defender (or put
another way, if it is related, then that's the same as it being a
Windows bug).

Here's my guess as to what might be happening. Apps that are installed
via the Windows Store or MSIX outside the store run using a
lightweight form of file system virtualization. This is how Windows
links files created in %APPDATA% to the app that created them,
ensuring they get cleaned up correctly at uninstall time.

https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes

The implementation involves a kernel driver called bindflt. In theory
this virtualization doesn't affect temporary directories, but the
combination of UNIX domain sockets+bindflt is probably not very common
at the moment, and it may be the case that the Windows team have
shipped a regression in some versions. Now if that theory is correct,
it doesn't really explain why some machines are affected and others
aren't when they all appear to be running the same OS version. That is
mysterious and I can't explain it, which counts against the bindflt
theory. An alternative possibility is that it's another race in
winsock; you previously had to do rollbacks due to the discovery of
such races which implies there might be more. But then we face the
question of why the packaging type appears to change the outcome on
the machines that do experience the bug.

Regardless of the cause the result is the same: new Javas can't be
used for apps distributed in this way. The best workaround would be to
detect that this codepath is failing with the stack trace in the first
email in this thread and fall back to the old TCP codepath. Is there
any chance you'd consider such a change? Also if anyone at Oracle has
contacts on the Windows team, it'd be great to ask them to investigate
the issue. I don't have any such contacts :(

thanks,
-mike

From michael.x.mcmahon at oracle.com  Wed Mar  8 11:35:44 2023
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 8 Mar 2023 11:35:44 +0000
Subject: UNIX domain sockets bug on Windows
In-Reply-To: <CAGv+2bOPuE2v92BmNqi=hGjiUuCoTEs7OX31yRa-N=ZZ8-X0JQ@mail.gmail.com>
References: <CAGv+2bNfkcq1X_kHgahq=peMKwmZ2QtRaHf-2xTXFMxXwb1xuQ@mail.gmail.com>
 <57459407-d234-1be3-94e0-8b52826f1e86@oracle.com>
 <CAGv+2bNwg02ZCUVhDd199dDZehgqXO+c1S75BhEY_caTnGTQBQ@mail.gmail.com>
 <247b5106-9d23-fc84-e602-ec0e75a5e2ca@oracle.com>
 <CAGv+2bOPuE2v92BmNqi=hGjiUuCoTEs7OX31yRa-N=ZZ8-X0JQ@mail.gmail.com>
Message-ID: <d967149d-4952-8d49-d1f3-a2736f4e88f8@oracle.com>

If this filter is doing filename remapping, then one thing worth trying 
is to run with the system property jdk.net.unixdomain.tmpdir set to some 
alternate location. This specifies the location of the directory where 
we create the socket files for "automatically" bound sockets for 
ServerSocketChannel (ie when binding with a null address). This is what 
the NIO PipeImpl does when creating its loopback socket.

Alternatively, you could try asking your customer to run a simple test 
of UNIX domain sockets on an affected machine and see what happens. Eg. 
the following snippet:

var server =ServerSocketChannel.open(StandardProtocolFamily.UNIX);
var name =Path.of("foo.sock");
Files.deleteIfExists(name);
server.bind(UnixDomainSocketAddress.of(name));
var client =SocketChannel.open(server.getLocalAddress());
var s1 =server.accept();
System.out.printf("client: %s, server connection: %s\n",client.toString(),s1.toString());

- Michael

On 08/03/2023 10:14, Mike Hearn wrote:
> Unfortunately I need to resurrect this thread. Although in November we
> worked around the issue by patching the JVM we ship with our
> applications, now the apps being shipped by one of our customers are
> hitting the exact same thing. Obviously telling them to make their own
> JVM builds with patches is not a workable solution here, nor really
> for anyone else.
>
> Here's what we know:
>
> 1. The problem occurs only on some machines but not others (but the
> machines affected are affected reliably).
>
> 2. For unclear reasons on those machines the problem only occurs if
> the app is installed using an MSIX package (the type used by the
> Windows Store). If the app is run from an ordinary zip, network
> connections function correctly. This is probably why you find it hard
> to reproduce. I can supply such an app if it would help with testing.
>
> 3. We don't think it's security software related because the affected
> machines don't use any beyond the built-in Windows Defender (or put
> another way, if it is related, then that's the same as it being a
> Windows bug).
>
> Here's my guess as to what might be happening. Apps that are installed
> via the Windows Store or MSIX outside the store run using a
> lightweight form of file system virtualization. This is how Windows
> links files created in %APPDATA% to the app that created them,
> ensuring they get cleaned up correctly at uninstall time.
>
> https://urldefense.com/v3/__https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes__;!!ACWV5N9M2RV99hQ!LjA2A-_P6j5L4VE77_w_iMpceuHJIhdeVkj2dv2mTJgFEc_y3FPOOTfOTLAa8LkAODbJlqd5nHhfcAiJm_29sB6uMb8B$  
>
> The implementation involves a kernel driver called bindflt. In theory
> this virtualization doesn't affect temporary directories, but the
> combination of UNIX domain sockets+bindflt is probably not very common
> at the moment, and it may be the case that the Windows team have
> shipped a regression in some versions. Now if that theory is correct,
> it doesn't really explain why some machines are affected and others
> aren't when they all appear to be running the same OS version. That is
> mysterious and I can't explain it, which counts against the bindflt
> theory. An alternative possibility is that it's another race in
> winsock; you previously had to do rollbacks due to the discovery of
> such races which implies there might be more. But then we face the
> question of why the packaging type appears to change the outcome on
> the machines that do experience the bug.
>
> Regardless of the cause the result is the same: new Javas can't be
> used for apps distributed in this way. The best workaround would be to
> detect that this codepath is failing with the stack trace in the first
> email in this thread and fall back to the old TCP codepath. Is there
> any chance you'd consider such a change? Also if anyone at Oracle has
> contacts on the Windows team, it'd be great to ask them to investigate
> the issue. I don't have any such contacts :(
>
> thanks,
> -mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230308/3723e665/attachment-0001.htm>

From djelinski at openjdk.org  Wed Mar  8 11:59:09 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 Mar 2023 11:59:09 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
Message-ID: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>

This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.

Other changes include:
- the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
- While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
- jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
- zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
- `getLastErrorString` is no longer exported by libjava.

Tier1-3 tests continue to pass.

No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.

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

Commit messages:
 - Update copyrights
 - Remove LastError
 - Change getLastErrorString to return a jstring

Changes: https://git.openjdk.org/jdk/pull/12922/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12922&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303814
  Stats: 138 lines in 8 files changed: 19 ins; 44 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/12922.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12922/head:pull/12922

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

From jpai at openjdk.org  Wed Mar  8 12:15:13 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Mar 2023 12:15:13 GMT
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support
 position > size()
In-Reply-To: <pRdb-ocGRTsX2-tUOV7Kr61k4_XP4n-ERx7w2Jb6zHA=.23331916-d798-47d1-af1c-aebbec4f0437@github.com>
References: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
 <pRdb-ocGRTsX2-tUOV7Kr61k4_XP4n-ERx7w2Jb6zHA=.23331916-d798-47d1-af1c-aebbec4f0437@github.com>
Message-ID: <qUp5TIL7lmzOxBVjD-iXySMEZh7qr-5F_Byb9pbgH5w=.a4958efe-e569-4279-957b-ec95bbced836@github.com>

On Sun, 5 Mar 2023 21:06:18 GMT, altrisi <duke at openjdk.org> wrote:

> Unrelated to the content of this PR, but the bot seems to be obsessed with editing the main comment description, at the time of writing it has made 4852 edits, seems to make around one per minute.

Noted. Thank you @altrisi. The team that deals with skara bots has been made aware of this issue https://bugs.openjdk.org/browse/SKARA-1837

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

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

From mike at hydraulic.software  Wed Mar  8 13:01:12 2023
From: mike at hydraulic.software (Mike Hearn)
Date: Wed, 8 Mar 2023 14:01:12 +0100
Subject: UNIX domain sockets bug on Windows
In-Reply-To: <d967149d-4952-8d49-d1f3-a2736f4e88f8@oracle.com>
References: <CAGv+2bNfkcq1X_kHgahq=peMKwmZ2QtRaHf-2xTXFMxXwb1xuQ@mail.gmail.com>
 <57459407-d234-1be3-94e0-8b52826f1e86@oracle.com>
 <CAGv+2bNwg02ZCUVhDd199dDZehgqXO+c1S75BhEY_caTnGTQBQ@mail.gmail.com>
 <247b5106-9d23-fc84-e602-ec0e75a5e2ca@oracle.com>
 <CAGv+2bOPuE2v92BmNqi=hGjiUuCoTEs7OX31yRa-N=ZZ8-X0JQ@mail.gmail.com>
 <d967149d-4952-8d49-d1f3-a2736f4e88f8@oracle.com>
Message-ID: <CAGv+2bN9MF8icsZYM6ro3-+Q22CfUmRgDtg721d0BT9Ci7xQcg@mail.gmail.com>

Thanks Michael, that's been a very useful suggestion. After I mailed,
we discovered a VM that could repro the problem. This let us check the
theory that it's FS virt related and indeed it is; disabling it fixes
the issue. It is still worth working around it in the JVM because not
everyone will see this thread and apps distributed via the MS Store
using their standard instructions will hit it.

To readers from the future! You have two ways to fix this if you're
using a JVM/Windows build with the issue. One way is to add the
following to the appropriate sections of your appx manifest:

<Properties>
  <virtualization:FileSystemWriteVirtualization>
    <virtualization:ExcludedDirectories>
      <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Temp\JavaSockets</virtualization:ExcludedDirectory>
    </virtualization:ExcludedDirectories>
  </virtualization:FileSystemWriteVirtualization>
</Properties>
<Capabilities>
  <rescap:Capability Name="unvirtualizedResources" />
</Capabilities>

and then on Windows set the system property jdk.net.unixdomain.tmpdir
= "%LOCALAPPDATA%/Temp/JavaSockets"

Or a better way, head over to https://hydraulic.software/ and download
Conveyor which works around this bug and (sadly) several other Windows
bugs for you.








On Wed, 8 Mar 2023 at 12:35, Michael McMahon
<michael.x.mcmahon at oracle.com> wrote:
>
> If this filter is doing filename remapping, then one thing worth trying is to run with the system property jdk.net.unixdomain.tmpdir set to some alternate location. This specifies the location of the directory where we create the socket files for "automatically" bound sockets for ServerSocketChannel (ie when binding with a null address). This is what the NIO PipeImpl does when creating its loopback socket.
>
> Alternatively, you could try asking your customer to run a simple test of UNIX domain sockets on an affected machine and see what happens. Eg. the following snippet:
>
> var server = ServerSocketChannel.open(StandardProtocolFamily.UNIX);
> var name = Path.of("foo.sock");
> Files.deleteIfExists(name);
> server.bind(UnixDomainSocketAddress.of(name));
> var client = SocketChannel.open(server.getLocalAddress());
> var s1 = server.accept();
> System.out.printf("client: %s, server connection: %s\n", client.toString(), s1.toString());
>
> - Michael
>
> On 08/03/2023 10:14, Mike Hearn wrote:
>
> Unfortunately I need to resurrect this thread. Although in November we
> worked around the issue by patching the JVM we ship with our
> applications, now the apps being shipped by one of our customers are
> hitting the exact same thing. Obviously telling them to make their own
> JVM builds with patches is not a workable solution here, nor really
> for anyone else.
>
> Here's what we know:
>
> 1. The problem occurs only on some machines but not others (but the
> machines affected are affected reliably).
>
> 2. For unclear reasons on those machines the problem only occurs if
> the app is installed using an MSIX package (the type used by the
> Windows Store). If the app is run from an ordinary zip, network
> connections function correctly. This is probably why you find it hard
> to reproduce. I can supply such an app if it would help with testing.
>
> 3. We don't think it's security software related because the affected
> machines don't use any beyond the built-in Windows Defender (or put
> another way, if it is related, then that's the same as it being a
> Windows bug).
>
> Here's my guess as to what might be happening. Apps that are installed
> via the Windows Store or MSIX outside the store run using a
> lightweight form of file system virtualization. This is how Windows
> links files created in %APPDATA% to the app that created them,
> ensuring they get cleaned up correctly at uninstall time.
>
> https://urldefense.com/v3/__https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes__;!!ACWV5N9M2RV99hQ!LjA2A-_P6j5L4VE77_w_iMpceuHJIhdeVkj2dv2mTJgFEc_y3FPOOTfOTLAa8LkAODbJlqd5nHhfcAiJm_29sB6uMb8B$
>
> The implementation involves a kernel driver called bindflt. In theory
> this virtualization doesn't affect temporary directories, but the
> combination of UNIX domain sockets+bindflt is probably not very common
> at the moment, and it may be the case that the Windows team have
> shipped a regression in some versions. Now if that theory is correct,
> it doesn't really explain why some machines are affected and others
> aren't when they all appear to be running the same OS version. That is
> mysterious and I can't explain it, which counts against the bindflt
> theory. An alternative possibility is that it's another race in
> winsock; you previously had to do rollbacks due to the discovery of
> such races which implies there might be more. But then we face the
> question of why the packaging type appears to change the outcome on
> the machines that do experience the bug.
>
> Regardless of the cause the result is the same: new Javas can't be
> used for apps distributed in this way. The best workaround would be to
> detect that this codepath is failing with the stack trace in the first
> email in this thread and fall back to the old TCP codepath. Is there
> any chance you'd consider such a change? Also if anyone at Oracle has
> contacts on the Windows team, it'd be great to ask them to investigate
> the issue. I don't have any such contacts :(
>
> thanks,
> -mike

From naoto at openjdk.org  Wed Mar  8 20:05:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 Mar 2023 20:05:16 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
In-Reply-To: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
Message-ID: <yRPLAkZluAaVwdihXjgn897b7S_xt3Zinzc2Z8KRS34=.43f06195-26af-4626-8a2f-3b0cafc0793c@github.com>

On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
> 
> Other changes include:
> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
> - `getLastErrorString` is no longer exported by libjava.
> 
> Tier1-3 tests continue to pass.
> 
> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.

Hi Daniel,
I like the idea of using `jstring` directly to avoid platform string. My concern is that is it OK to make it not export from libjava? Would it cause any concern on other platforms? Also, now it is not consistent with the other sibling `getErrorString()` call.

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

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

From djelinski at openjdk.org  Wed Mar  8 22:03:14 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 Mar 2023 22:03:14 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
In-Reply-To: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
Message-ID: <OAIVFR5dQsofGlPqtPtAnk7cMoPKfUVyIvM8_wb-8XU=.524b171c-6b3d-41d3-9a2d-d9e43aabb73c@github.com>

On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
> 
> Other changes include:
> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
> - `getLastErrorString` is no longer exported by libjava.
> 
> Tier1-3 tests continue to pass.
> 
> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.

I think it's fine to remove `getLastErrorString` from the list of libjava exports. After my changes it's no longer used outside libjava, and it was never a part of the JDK's public interface.

Regarding consistency with `getErrorString`, I'm not too concerned about that; the functions have similar names but serve different purposes.

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

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

From cjplummer at openjdk.org  Wed Mar  8 23:26:13 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Mar 2023 23:26:13 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
In-Reply-To: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
Message-ID: <KWovrmxEjrz2rKelc8Np3WoRhoVSuPJdXOIs7pnSH10=.32ee91b7-6602-4fee-953c-c281c4ca7ed8@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
> 
> Other changes include:
> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
> - `getLastErrorString` is no longer exported by libjava.
> 
> Tier1-3 tests continue to pass.
> 
> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.

We don't have a test for the SA changes you made. The best way to test it is with clhsdb. Run the following against a JVM pid:

`$ jhsdb clhsdb --pid <pid>`

Use "jstack -v" to get a native pc from a frame, and then try `disassemble` on the address. It most likely will produce an exception since it can't find hsdis, which is actually what we want to be testing in this case:


hsdb> disassemble 0x00007f38b371fca0
Error: sun.jvm.hotspot.debugger.DebuggerException: hsdis-amd64.so: cannot open shared object file: No such file or directory


You'll need to test separately on Windows and any unix platform.

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

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

From alanb at openjdk.org  Thu Mar  9 08:17:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Mar 2023 08:17:41 GMT
Subject: Integrated: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
In-Reply-To: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
References: <kL3tEiGh49bIN6gOisp4z5vgH2fxZUQFgeCLsT__D1Q=.004c77b0-c5e6-4b11-990a-349c19ed63fc@github.com>
Message-ID: <mN9gZfPEi7Pi1laObiRdeORguaaOdGeAJyDj-HLxDag=.0cc38027-c29a-461f-b51c-86f3ec587b23@github.com>

On Sun, 5 Mar 2023 09:33:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a small update to the underlying implementation of Socket.setTrafficClass so that it attempts to set the IP_TOS socket option when the socket is IPv6 and the operating system allows this option to be set on IPv6 sockets. The change is deliberately limited to the SocketImpl and SocketChannel implementation to avoid impacting DatagramChannel.
> 
> Socket.setTrafficClass is specified as a hint. For TCP connections it is possible on some platforms to set IP_TOS on an unbound socket to the ToS value to use in the SYN packet when establishing a connection. Setting it after a connection is established is possible on some platforms too. The JDK uses IPv6 sockets since JDK 1.4 so it gets a bit more complicated due to patchy support for IP_TOS.
> 
> - Linux allows IP_TOS to be set on an IPv6 socket at any time. If set on an unbound socket then the ToS will have the expected value when establishing a connection and it can be changed any time after connecting.
> - macOS doesn't allow IP_TOS to be set on an IPv6 socket and it doesn't use the IPV6_TCLASS value as the IPv4 ToS. So on macOS, you have to use an IPv4 socket and set IP_TOS before connecting the socket.
> - Windows hasn't allowed applications change the ToS for a long time. It allows the IP_TOS to be set on an unbound IPv6 socket but the value is not used.
> 
> The bug report report is Socket.setTrafficClass hasn't worked on Linux since JDK 13 when the SocketImpl was replaced. The workaround is to run with-Djava.net.preferIPv4=true. 
> 
> The proposed change is to just attempt to set both IPV6_TCLASS and IP_TOS when the socket is IPv6 and the operating system allows IPPROTO level sockets to be setup on IPv6 sockets. At some point I'd like to replace the underlying socket options implementation as it no longer needs to be in libnet, and that would be the limit to re-visit the equivalent in the channel implementations.
> 
> I had to use tcpdump and strace to test the changes, I don't think it's possible to create an automated test for this change.

This pull request has now been integrated.

Changeset: dd794108
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd79410824fa57c7fb1ce56c643bb52540f9a206
Stats:     32 lines in 5 files changed: 17 ins; 1 del; 14 mod

8303509: Socket setTrafficClass does not work for IPv4 connections when IPv6 enabled

Reviewed-by: djelinski, michaelm

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

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

From djelinski at openjdk.org  Thu Mar  9 08:54:06 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 9 Mar 2023 08:54:06 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
In-Reply-To: <KWovrmxEjrz2rKelc8Np3WoRhoVSuPJdXOIs7pnSH10=.32ee91b7-6602-4fee-953c-c281c4ca7ed8@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
 <KWovrmxEjrz2rKelc8Np3WoRhoVSuPJdXOIs7pnSH10=.32ee91b7-6602-4fee-953c-c281c4ca7ed8@github.com>
Message-ID: <Kk2PYa4rdGlXYYxwIb-rK6aKCWT4PFo33fTcuDtsOF8=.19031620-babe-4b82-b9a7-a56b911ab7fa@github.com>

On Wed, 8 Mar 2023 23:23:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
>> 
>> Other changes include:
>> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
>> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
>> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
>> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
>> - `getLastErrorString` is no longer exported by libjava.
>> 
>> Tier1-3 tests continue to pass.
>> 
>> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
>> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.
>
> We don't have a test for the SA changes you made. The best way to test it is with clhsdb. Run the following against a JVM pid:
> 
> `$ jhsdb clhsdb --pid <pid>`
> 
> Use "jstack -v" to get a native pc from a frame, and then try `disassemble` on the address. It most likely will produce an exception since it can't find hsdis, which is actually what we want to be testing in this case:
> 
> 
> hsdb> disassemble 0x00007f38b371fca0
> Error: sun.jvm.hotspot.debugger.DebuggerException: hsdis-amd64.so: cannot open shared object file: No such file or directory
> 
> 
> You'll need to test separately on Windows and any unix platform.

Thanks @plummercj for the instructions. Here's the results:
Linux, with this change applied:

hsdb> disassemble 0x00007f3484558da0
Error: sun.jvm.hotspot.debugger.DebuggerException: hsdis-amd64.so: cannot open shared object file: No such file or directory

Windows, EN, with the change:

hsdb> disassemble 0x00000107d4dae0c6
Error: sun.jvm.hotspot.debugger.DebuggerException: The specified module could not be found

Windows, misconfigured CN, without the change:

hsdb> disassemble 0x00000200d60de0b4
Error: sun.jvm.hotspot.debugger.DebuggerException: ?????????

Windows, misconfigured CN, with the change:

hsdb> disassemble 0x000001fab996e0b4
Error: sun.jvm.hotspot.debugger.DebuggerException: ?????????

(note: I had to run `chcp 65001` in the console, otherwise the exception would still display incorrectly)

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

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

From naoto at openjdk.org  Thu Mar  9 18:15:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 9 Mar 2023 18:15:41 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
In-Reply-To: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
Message-ID: <AyPPlmMJpvB2-dbHUHKvD6czbC1o_7pnRFC3LJRw3nQ=.416fdc11-31d1-44a8-a950-697be52b4ec7@github.com>

On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
> 
> Other changes include:
> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
> - `getLastErrorString` is no longer exported by libjava.
> 
> Tier1-3 tests continue to pass.
> 
> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.

Looks good (w/ some minor comments)

src/java.base/share/native/libzip/zip_util.c line 767:

> 765:  * or NULL if an error occurred. If a zip error occurred then *pmsg will
> 766:  * be set to the error message text if pmsg != 0. Otherwise, *pmsg will be
> 767:  * set to NULL. Caller doesn't need to free the error message.

I'd put some more context here why the caller does not need to free. (as it is a static text)

src/java.base/windows/native/libjava/jni_util_md.c line 80:

> 78:                 0,
> 79:                 buf,
> 80:                 sizeof(buf) / sizeof(WCHAR),

Maybe better to #define the size 256 so that this division is not needed.

src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 208:

> 206: 
> 207:     if (result == 0) {
> 208:         JNU_ThrowIOExceptionWithLastError(env, "Write failed");

Could be replaced with `JNU_ThrowIOException`?

src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 260:

> 258: 
> 259:     if (result == 0) {
> 260:         JNU_ThrowIOExceptionWithLastError(env, "Write failed");

Same as above

src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 299:

> 297: 
> 298:     if (result == 0) {
> 299:         JNU_ThrowIOExceptionWithLastError(env, "Write failed");

Same here

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

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

From bpb at openjdk.org  Fri Mar 10 00:43:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Mar 2023 00:43:04 GMT
Subject: RFR: 8303934: (fc) Use splice in FileChannel::transferFrom when the
 source is a pipe (Linux)
Message-ID: <qjBAxvqqoexYZXsXchq4VKJAPZrVY7EWkfQXDV_nJrw=.644d2265-4a97-4e7c-b274-926bc729d159@github.com>

On Linux, perform `transferFrom()` via the `splice(2)` system call when the source `ReadableByteChannel` is a `Pipe.SourceChannel` (`sun.nio.ch.SourceChannelImpl`).

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

Commit messages:
 - 8303934: (fc) Use splice in FileChannel::transferFrom when the source is a pipe (Linux)

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

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

From bpb at openjdk.org  Fri Mar 10 00:43:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Mar 2023 00:43:04 GMT
Subject: RFR: 8303934: (fc) Use splice in FileChannel::transferFrom when
 the source is a pipe (Linux)
In-Reply-To: <qjBAxvqqoexYZXsXchq4VKJAPZrVY7EWkfQXDV_nJrw=.644d2265-4a97-4e7c-b274-926bc729d159@github.com>
References: <qjBAxvqqoexYZXsXchq4VKJAPZrVY7EWkfQXDV_nJrw=.644d2265-4a97-4e7c-b274-926bc729d159@github.com>
Message-ID: <Ghe2BNk8ez_AMacsr_H8llC7mGss2ANx7-c8wrZruFM=.90e14c32-ab6b-4793-949f-26f2aa719f44@github.com>

On Fri, 10 Mar 2023 00:35:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On Linux, perform `transferFrom()` via the `splice(2)` system call when the source `ReadableByteChannel` is a `Pipe.SourceChannel` (`sun.nio.ch.SourceChannelImpl`).

The Linux `splice()` system call copies data in kernel address space between two file descriptors without copying the data to user address space. At present the execution pathway for transferring from a pipe source is the arbitrary channel pathway which is the slowest. Using `splice()` for this case increases throughput by more than 30%. This is the increase measured using this simple benchmark (excerpt) for a buffer of capacity 8192:


    ByteBuffer buf;
    Pipe pipe;
    FileChannel fc;

    @Benchmark
    public long transferFromPipe() throws IOException {
        pipe.sink().write(buf);
        buf.rewind();
        return fc.transferFrom(pipe.source(), 0, SIZE);
    }

As the benchmark measurement includes writing to the pipe sink, the increase in throughput should actually be larger than that measured.

Test tiers 1-3 pass on all platforms.

The modifications to the AIX and Windows source files are format cleanup only.

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

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

From bpb at openjdk.org  Fri Mar 10 01:26:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Mar 2023 01:26:10 GMT
Subject: RFR: 8303934: (fc) Use splice in FileChannel::transferFrom when
 the source is a pipe (Linux)
In-Reply-To: <qjBAxvqqoexYZXsXchq4VKJAPZrVY7EWkfQXDV_nJrw=.644d2265-4a97-4e7c-b274-926bc729d159@github.com>
References: <qjBAxvqqoexYZXsXchq4VKJAPZrVY7EWkfQXDV_nJrw=.644d2265-4a97-4e7c-b274-926bc729d159@github.com>
Message-ID: <oXRtsO1NU8-BvQN4gIXGZgteklvz6rJO9Znl9JwgP1g=.132ef958-9df3-4f17-9763-53e1cf5e4c0c@github.com>

On Fri, 10 Mar 2023 00:35:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On Linux, perform `transferFrom()` via the `splice(2)` system call when the source `ReadableByteChannel` is a `Pipe.SourceChannel` (`sun.nio.ch.SourceChannelImpl`).

The Linux system call `copy_file_range(2)` does not work with pipes. In the case of `FileChannel::transferTo` writing to a pipe, the native code path falls back to `sendfile(2)` which does handle a destination pipe so `splice(2)` is not needed there. The `offset` parameter of `sendfile()` however refers to the input so that call is not usable in `FileChannel::transferFrom` which requires the position in the output, i.e., the channel?s file.

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

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

From cjplummer at openjdk.org  Fri Mar 10 05:50:03 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 10 Mar 2023 05:50:03 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
In-Reply-To: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
Message-ID: <SUBT-M1ZM-Vizmhmt-F8j89f0oxTDkF0ncs77bZ2jcY=.4f602ef3-14eb-45b1-93e2-5071ea135698@github.com>

On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
> 
> Other changes include:
> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
> - `getLastErrorString` is no longer exported by libjava.
> 
> Tier1-3 tests continue to pass.
> 
> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.

I'm approving the SA changes. Thanks for the testing.

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

Marked as reviewed by cjplummer (Reviewer).

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

From djelinski at openjdk.org  Fri Mar 10 08:06:16 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 10 Mar 2023 08:06:16 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
In-Reply-To: <AyPPlmMJpvB2-dbHUHKvD6czbC1o_7pnRFC3LJRw3nQ=.416fdc11-31d1-44a8-a950-697be52b4ec7@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
 <AyPPlmMJpvB2-dbHUHKvD6czbC1o_7pnRFC3LJRw3nQ=.416fdc11-31d1-44a8-a950-697be52b4ec7@github.com>
Message-ID: <I2rsru5QvmlUrtpEb9QPLXlOZboXwha0xGD5LMi0Q-8=.78523e60-9e0d-49fe-b0ca-5c5f4cf3f62b@github.com>

On Thu, 9 Mar 2023 00:17:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
>> 
>> Other changes include:
>> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
>> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
>> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
>> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
>> - `getLastErrorString` is no longer exported by libjava.
>> 
>> Tier1-3 tests continue to pass.
>> 
>> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
>> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.
>
> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 208:
> 
>> 206: 
>> 207:     if (result == 0) {
>> 208:         JNU_ThrowIOExceptionWithLastError(env, "Write failed");
> 
> Could be replaced with `JNU_ThrowIOException`?

If we got here, `WriteFile` just failed and `GetLastError` contains interesting information.
`JNU_ThrowIOExceptionWithLastError` will generate specific error message in user's language, `JNU_ThrowIOException` would just throw `Write failed`. I don't think we want to change this.

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

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

From alanb at openjdk.org  Fri Mar 10 10:43:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Mar 2023 10:43:14 GMT
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support
 position > size()
In-Reply-To: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
References: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
Message-ID: <wDANDzzwbTxuIts3HeN0d0DMyi20ZKRkK3LiLl3jO6U=.5293edf4-535f-487c-a077-837b79146e88@github.com>

On Wed, 1 Mar 2023 01:34:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Enhance `FileChannel::transferFrom` to extend the channel's file if `position > size()`. This is consistent with `FileChannel::write(ByteBuffer, long)`.

The spec + impl changes looks fine. 

Is this test copied/edited from an older test? Configuration name FAST_TRANSFER_xxx looks a bit odd and maybe we just replace it with a simpler JUnit style test?

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

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

From duke at openjdk.org  Fri Mar 10 15:39:05 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 10 Mar 2023 15:39:05 GMT
Subject: RFR: 8303972: TestLocOffsetFromZip64EF could use a sparse file
Message-ID: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>

Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.

By using a sparse ZIP file instead of calling out to the `zip` command line, we can speed up the test (from 50s to 3s on my Macbook Pro), save 4GB disk space during builds and remove a dependency on the `zip` command in OS/distros.

To get an idea on how the new test performs on file systems which do not support sparse files, I also ran the using a disk image in MacOS with a non-spase file system. The test completed in 14 seconds.

Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.

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

Commit messages:
 - Remove accidentally introduced blank line
 - Merge branch 'master' into loc-offset-zip64-sparse
 - Rewrite TestLocOffsetFromZip64EF to create ZIP file using sparse ZipOutputStream instead of calling out to the ZIP command line

Changes: https://git.openjdk.org/jdk/pull/12979/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12979&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303972
  Stats: 120 lines in 2 files changed: 20 ins; 56 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/12979.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12979/head:pull/12979

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

From brian.burkhalter at oracle.com  Fri Mar 10 15:39:08 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 10 Mar 2023 15:39:08 +0000
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support
 position > size()
In-Reply-To: <wDANDzzwbTxuIts3HeN0d0DMyi20ZKRkK3LiLl3jO6U=.5293edf4-535f-487c-a077-837b79146e88@github.com>
References: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
 <wDANDzzwbTxuIts3HeN0d0DMyi20ZKRkK3LiLl3jO6U=.5293edf4-535f-487c-a077-837b79146e88@github.com>
Message-ID: <49AC3CAF-1512-47A5-B502-AB6A68A66E5F@oracle.com>


On Mar 10, 2023, at 2:43 AM, Alan Bateman <alanb at openjdk.org<mailto:alanb at openjdk.org>> wrote:

On Wed, 1 Mar 2023 01:34:33 GMT, Brian Burkhalter <bpb at openjdk.org<mailto:bpb at openjdk.org>> wrote:

Enhance `FileChannel::transferFrom` to extend the channel's file if `position > size()`. This is consistent with `FileChannel::write(ByteBuffer, long)`.

The spec + impl changes looks fine.

Is this test copied/edited from an older test?

No, I don?t recall doing that.

Configuration name FAST_TRANSFER_xxx looks a bit odd and maybe we just replace it with a simpler JUnit style test?

Will investigate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230310/1be57c51/attachment.htm>

From duke at openjdk.org  Fri Mar 10 20:21:15 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 10 Mar 2023 20:21:15 GMT
Subject: RFR: 8303972: TestLocOffsetFromZip64EF could use a sparse file
 [v2]
In-Reply-To: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
Message-ID: <DTwAkhqyjUX92jqp3xgPjBs4oOfFMX-FsFiApSQsC4Y=.dba75d13-29b2-460c-ac72-66410cff3f68@github.com>

> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
> 
> By using a sparse ZIP file instead of calling out to the `zip` command line, we can speed up the test (from 50s to 3s on my Macbook Pro), save 4GB disk space during builds and remove a dependency on the `zip` command in OS/distros.
> 
> To get an idea on how the new test performs on file systems which do not support sparse files, I also ran the using a disk image in MacOS with a non-spase file system. The test completed in 14 seconds.
> 
> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.

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

  Instead of making a big file to force Zip64, make a small file with a Zip64-formatted CEN header.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12979/files
  - new: https://git.openjdk.org/jdk/pull/12979/files/ee8adc0c..2efd7275

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

  Stats: 107 lines in 1 file changed: 49 ins; 23 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/12979.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12979/head:pull/12979

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

From duke at openjdk.org  Fri Mar 10 20:50:05 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 10 Mar 2023 20:50:05 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v3]
In-Reply-To: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
Message-ID: <ZaxcfDGBpg2xQJciP5d5cWWY1XkiSF8kCiOi9DuNEa0=.70cc589b-7f3f-4ebb-b41a-582e846ca227@github.com>

> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
> 
> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' extended field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
> 
> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
> 
> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.

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

  The Zip64 fields are all zero, we don't need to update them

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12979/files
  - new: https://git.openjdk.org/jdk/pull/12979/files/2efd7275..2a68bd89

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

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

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

From lancea at openjdk.org  Fri Mar 10 21:18:06 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 10 Mar 2023 21:18:06 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v3]
In-Reply-To: <ZaxcfDGBpg2xQJciP5d5cWWY1XkiSF8kCiOi9DuNEa0=.70cc589b-7f3f-4ebb-b41a-582e846ca227@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <ZaxcfDGBpg2xQJciP5d5cWWY1XkiSF8kCiOi9DuNEa0=.70cc589b-7f3f-4ebb-b41a-582e846ca227@github.com>
Message-ID: <KPMI80yyPpnt2KAifuR2UYg4Xojv88gcBBdCOAVfo-c=.a85986a4-d8f2-468d-87a9-1dcd176b5b5a@github.com>

On Fri, 10 Mar 2023 20:50:05 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
>> 
>> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' extended field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
>> 
>> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
>> 
>> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The Zip64 fields are all zero, we don't need to update them

This test was leveraging a file created by info-zip intentionally so care needs to be taken to ensure that the zip that is being created is similar LOC and CEN output

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

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

From duke at openjdk.org  Fri Mar 10 21:18:08 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 10 Mar 2023 21:18:08 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line
In-Reply-To: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
Message-ID: <chtTlCknDmg-rwERaAqxf3aYHgqmNSUEnDVnmGzEEGA=.253af540-fb49-48ec-95a0-7f96a776f705@github.com>

On Fri, 10 Mar 2023 15:10:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
> 
> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' extended field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
> 
> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
> 
> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.

Converting to draft while I investigate why the updated test does not actually catch the regression

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

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

From duke at openjdk.org  Fri Mar 10 21:18:09 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 10 Mar 2023 21:18:09 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v3]
In-Reply-To: <KPMI80yyPpnt2KAifuR2UYg4Xojv88gcBBdCOAVfo-c=.a85986a4-d8f2-468d-87a9-1dcd176b5b5a@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <ZaxcfDGBpg2xQJciP5d5cWWY1XkiSF8kCiOi9DuNEa0=.70cc589b-7f3f-4ebb-b41a-582e846ca227@github.com>
 <KPMI80yyPpnt2KAifuR2UYg4Xojv88gcBBdCOAVfo-c=.a85986a4-d8f2-468d-87a9-1dcd176b5b5a@github.com>
Message-ID: <IqQK0tlMuuJeKcmV9V3ewJQ0g5xP93EtEH4Ubrnrm0M=.4796555b-6b54-41d3-876a-b43dcaa20d7b@github.com>

On Fri, 10 Mar 2023 16:56:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> This test was leveraging a file created by info-zip intentionally so care needs to be taken to ensure that the zip that is being created is similar LOC and CEN output

Yes, I just noticed that and currently looking into it.  I think in particular it is sensitive to the ordering of the extended time stamp and the Zip64 entries, which is not the same as ZipOutputStream.

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

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

From duke at openjdk.org  Fri Mar 10 21:18:11 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 10 Mar 2023 21:18:11 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v2]
In-Reply-To: <DTwAkhqyjUX92jqp3xgPjBs4oOfFMX-FsFiApSQsC4Y=.dba75d13-29b2-460c-ac72-66410cff3f68@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <DTwAkhqyjUX92jqp3xgPjBs4oOfFMX-FsFiApSQsC4Y=.dba75d13-29b2-460c-ac72-66410cff3f68@github.com>
Message-ID: <j52FKMiQpTsD5N7hn2SYGKs43ORh6ONsG9OW3RTRGrs=.92a367f4-3a5b-44c2-9589-9e9a3f1df7bf@github.com>

On Fri, 10 Mar 2023 20:21:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
>> 
>> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' extended field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
>> 
>> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
>> 
>> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Instead of making a big file to force Zip64, make a small file with a Zip64-formatted CEN header.

While it is possible to use a sparse file here, there is a problem that when ZipFileSystem reads inside a 'hole', it will skip ahead to the next data which turned out to be a LOC header. We could  carefully select an entry size such that 0XFFFFFFFF does not not fall into in a hole, but that feels a bit too magic.

Instead, I opted for creating a small ZIP file with a Zip64-formatted CEN. Since this issue is sensitive to ordering of extra fields, the 'extended timestamp' needs to come before the 'Zip64 extended information field'.

The way I solve this is to add an opaque extra field, right sized for 'Zip64'. This uses a tag ID unknown to ZipEntry.setExtra, such that it will not be parsed as Zip64 but simply passed through. ZipOutputStream will output this after the extended timestamp.

After the ZIP is produced, the Zip64 entry is updated with the correct tag.

I have verified that this causes ZipFileSystem (before JDK-8255380) to attempt to read the LOC from 0xFFFFFFFF. With a small file size, this causes a slightly different error message because of the attempt to read beyond the end of the file.


----------System.out:(160/10450)----------
config TestLocOffsetFromZip64EF.setUp(): success
test TestLocOffsetFromZip64EF.walkZipFSTest({}): failure
java.util.zip.ZipException: loc: reading failed
	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readExtra(ZipFileSystem.java:3127)
	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readCEN(ZipFileSystem.java:2831)
	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.<init>(ZipFileSystem.java:2767)
	at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.getFileAttributes(ZipFileSystem.java:550)
```  

While the symptom is slightly different, the cause is the same: ZipFileSystem tries to read the LOC at offset 0xFFFFFFFF because it has not read the Zip64 entry yet.

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

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

From alanb at openjdk.org  Fri Mar 10 21:18:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Mar 2023 21:18:13 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v3]
In-Reply-To: <ZaxcfDGBpg2xQJciP5d5cWWY1XkiSF8kCiOi9DuNEa0=.70cc589b-7f3f-4ebb-b41a-582e846ca227@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <ZaxcfDGBpg2xQJciP5d5cWWY1XkiSF8kCiOi9DuNEa0=.70cc589b-7f3f-4ebb-b41a-582e846ca227@github.com>
Message-ID: <PU6nCS9yUjRDLjnenCwcnUn9C_w5MTJa4ALR3czothE=.b6b5a783-634b-4ebc-b0aa-5177feff30b7@github.com>

On Fri, 10 Mar 2023 20:50:05 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
>> 
>> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' extended field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
>> 
>> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
>> 
>> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The Zip64 fields are all zero, we don't need to update them

test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 136:

> 134:         // Make a ZIP with two entries
> 135:         try (FileOutputStream fileOutputStream = new FileOutputStream(new File(ZIP_FILE_NAME));
> 136:              ZipOutputStream zo = new ZipOutputStream(new SparseOutputStream(fileOutputStream))) {

Can you use FileChannel.open and specify SPARSE in the set of open options, I think that would make it clearer that the file is sparse and remove the need for SparseOutputStream.

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

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

From duke at openjdk.org  Fri Mar 10 21:18:14 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 10 Mar 2023 21:18:14 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v3]
In-Reply-To: <PU6nCS9yUjRDLjnenCwcnUn9C_w5MTJa4ALR3czothE=.b6b5a783-634b-4ebc-b0aa-5177feff30b7@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <ZaxcfDGBpg2xQJciP5d5cWWY1XkiSF8kCiOi9DuNEa0=.70cc589b-7f3f-4ebb-b41a-582e846ca227@github.com>
 <PU6nCS9yUjRDLjnenCwcnUn9C_w5MTJa4ALR3czothE=.b6b5a783-634b-4ebc-b0aa-5177feff30b7@github.com>
Message-ID: <lYeklqF2a721AEQhu1D8Rz050vcWcnr0cwrhUPkFx6I=.a2c74998-a67c-46bf-9151-48934e2a66aa@github.com>

On Fri, 10 Mar 2023 15:48:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The Zip64 fields are all zero, we don't need to update them
>
> test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 136:
> 
>> 134:         // Make a ZIP with two entries
>> 135:         try (FileOutputStream fileOutputStream = new FileOutputStream(new File(ZIP_FILE_NAME));
>> 136:              ZipOutputStream zo = new ZipOutputStream(new SparseOutputStream(fileOutputStream))) {
> 
> Can you use FileChannel.open and specify SPARSE in the set of open options, I think that would make it clearer that the file is sparse and remove the need for SparseOutputStream.

Not sure I understand. I could use FileChannel.open with SPARSE (which btw is ignored by the implementation:), but that doesn't give me an OutputStream I can pass to ZipOutputStream?

I could use Channels.newOutputStream, but that would not create holes in the sparse files?

My current thinking is that we need the SparseOutputStream to detect that ZIpOutputStream is writing empty bytes and replace that with `channel.position(channel.position() + len)`

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

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

From alanb at openjdk.org  Fri Mar 10 21:18:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Mar 2023 21:18:14 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v3]
In-Reply-To: <lYeklqF2a721AEQhu1D8Rz050vcWcnr0cwrhUPkFx6I=.a2c74998-a67c-46bf-9151-48934e2a66aa@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <ZaxcfDGBpg2xQJciP5d5cWWY1XkiSF8kCiOi9DuNEa0=.70cc589b-7f3f-4ebb-b41a-582e846ca227@github.com>
 <PU6nCS9yUjRDLjnenCwcnUn9C_w5MTJa4ALR3czothE=.b6b5a783-634b-4ebc-b0aa-5177feff30b7@github.com>
 <lYeklqF2a721AEQhu1D8Rz050vcWcnr0cwrhUPkFx6I=.a2c74998-a67c-46bf-9151-48934e2a66aa@github.com>
Message-ID: <JhzKdR7EZ_iqOBpjsj_AfsrOJvfYfGjAJpTF5rmvk78=.0541756d-ec13-4c90-9515-e75845b41b74@github.com>

On Fri, 10 Mar 2023 15:54:12 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Not sure I understand. I could use FileChannel.open with SPARSE (which btw is ignored by the implementation:)

That is true on platforms where files can be sparse by default. On Windows you'll see this translates to create the file as sparse, it needs to be opt-in when creating the file.

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

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

From duke at openjdk.org  Fri Mar 10 21:18:14 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 10 Mar 2023 21:18:14 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v3]
In-Reply-To: <JhzKdR7EZ_iqOBpjsj_AfsrOJvfYfGjAJpTF5rmvk78=.0541756d-ec13-4c90-9515-e75845b41b74@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <ZaxcfDGBpg2xQJciP5d5cWWY1XkiSF8kCiOi9DuNEa0=.70cc589b-7f3f-4ebb-b41a-582e846ca227@github.com>
 <PU6nCS9yUjRDLjnenCwcnUn9C_w5MTJa4ALR3czothE=.b6b5a783-634b-4ebc-b0aa-5177feff30b7@github.com>
 <lYeklqF2a721AEQhu1D8Rz050vcWcnr0cwrhUPkFx6I=.a2c74998-a67c-46bf-9151-48934e2a66aa@github.com>
 <JhzKdR7EZ_iqOBpjsj_AfsrOJvfYfGjAJpTF5rmvk78=.0541756d-ec13-4c90-9515-e75845b41b74@github.com>
Message-ID: <SyaO4NYfnRWuCe0diwx5QNdenKdUn-tX9aaaCRMETkw=.64fcf1cc-0d42-443e-a5ef-a7a71c961668@github.com>

On Fri, 10 Mar 2023 16:58:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Not sure I understand. I could use FileChannel.open with SPARSE (which btw is ignored by the implementation:), but that doesn't give me an OutputStream I can pass to ZipOutputStream?
>> 
>> I could use Channels.newOutputStream, but that would not create holes in the sparse files?
>> 
>> My current thinking is that we need the SparseOutputStream to detect that ZIpOutputStream is writing empty bytes and replace that with `channel.position(channel.position() + len)`
>
>> Not sure I understand. I could use FileChannel.open with SPARSE (which btw is ignored by the implementation:)
> 
> That is true on platforms where files can be sparse by default. On Windows you'll see this translates to create the file as sparse, it needs to be opt-in when creating the file.

I opted to create a small-sized Zip64 file instead (see below). This file does not need to be sparse.

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

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

From duke at openjdk.org  Fri Mar 10 21:18:14 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 10 Mar 2023 21:18:14 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v3]
In-Reply-To: <SyaO4NYfnRWuCe0diwx5QNdenKdUn-tX9aaaCRMETkw=.64fcf1cc-0d42-443e-a5ef-a7a71c961668@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <ZaxcfDGBpg2xQJciP5d5cWWY1XkiSF8kCiOi9DuNEa0=.70cc589b-7f3f-4ebb-b41a-582e846ca227@github.com>
 <PU6nCS9yUjRDLjnenCwcnUn9C_w5MTJa4ALR3czothE=.b6b5a783-634b-4ebc-b0aa-5177feff30b7@github.com>
 <lYeklqF2a721AEQhu1D8Rz050vcWcnr0cwrhUPkFx6I=.a2c74998-a67c-46bf-9151-48934e2a66aa@github.com>
 <JhzKdR7EZ_iqOBpjsj_AfsrOJvfYfGjAJpTF5rmvk78=.0541756d-ec13-4c90-9515-e75845b41b74@github.com>
 <SyaO4NYfnRWuCe0diwx5QNdenKdUn-tX9aaaCRMETkw=.64fcf1cc-0d42-443e-a5ef-a7a71c961668@github.com>
Message-ID: <cO1eKrToWPkSpKccPLMK1eN1S3vcI2Rlefd8xvmeLJ8=.7c21a34f-20ae-4ad8-a0f5-8b6f24e97557@github.com>

On Fri, 10 Mar 2023 20:34:56 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>>> Not sure I understand. I could use FileChannel.open with SPARSE (which btw is ignored by the implementation:)
>> 
>> That is true on platforms where files can be sparse by default. On Windows you'll see this translates to create the file as sparse, it needs to be opt-in when creating the file.
>
> I opted to create a small-sized Zip64 file instead (see below). This file does not need to be sparse.

> That is true on platforms where files can be sparse by default. On Windows you'll see this translates to create the file as sparse, it needs to be opt-in when creating the file.

Thanks for this info, Alan!

While this PR no longer makes use of sparse files, I have applied your comments about FileChannel.open for NTFS in another PR (which does make use of sparse files):

https://github.com/openjdk/jdk/pull/12948

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

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

From rriggs at openjdk.org  Fri Mar 10 22:05:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 10 Mar 2023 22:05:16 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
In-Reply-To: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
Message-ID: <gS2hCnJ8ArwPZ1ew9Q2qrzJShiTmEtFuMRiJzGknSXc=.884e89eb-37cd-4fbc-a04b-b58c9ef2a69f@github.com>

On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
> 
> Other changes include:
> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
> - `getLastErrorString` is no longer exported by libjava.
> 
> Tier1-3 tests continue to pass.
> 
> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.

src/java.base/share/native/libjava/jni_util.c line 133:

> 131:     if (s != NULL) {
> 132:         jobject x = NULL;
> 133:         if (messagelen) {

Avoid implicit compare with 0; use `messagelen > 0` or similar.

src/java.base/share/native/libjava/jni_util.c line 137:

> 135:             size_t messageextlen = messagelen + 4;
> 136:             char *str1 = (char *)malloc((messageextlen) * sizeof(char));
> 137:             if (str1 == 0) {

Use NULL when comparing to a pointer.

src/java.base/unix/native/libjava/jni_util_md.c line 69:

> 67:     if (errno == 0) return NULL;
> 68:     getErrorString(errno, buf, sizeof(buf));
> 69:     return (*buf) ? JNU_NewStringPlatform(env, buf) : NULL;

I would have used `buf[0] != 0` since its declared as a local buffer; but this file doesn't have much of a style to follow.

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

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

From duke at openjdk.org  Sat Mar 11 07:28:14 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 11 Mar 2023 07:28:14 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v4]
In-Reply-To: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
Message-ID: <UE1Ihj1cgnu2H0mbL2PID2wjvd8z378NqmL9h_gdMPw=.c6b8e321-44f6-4e81-aefb-3cad76481cf8@github.com>

> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
> 
> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
> 
> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
> 
> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.

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

  APPNOTE.txt actually specifies an 'unknown' tag, let's use that instead of 0x42

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12979/files
  - new: https://git.openjdk.org/jdk/pull/12979/files/2a68bd89..22eba5c3

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

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

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

From Brian.Stafford at microsoft.com  Fri Mar 10 00:20:36 2023
From: Brian.Stafford at microsoft.com (Brian Stafford)
Date: Fri, 10 Mar 2023 00:20:36 +0000
Subject: UNIX domain sockets bug on Windows
Message-ID: <SN7PR21MB3952DD678FAD62F3CE4B1FD586BA9@SN7PR21MB3952.namprd21.prod.outlook.com>

Hi Mike,

We'll follow up on this bug report with the Windows team.

Thanks,
Brian Stafford 
he/him 
Principal Software Engineering Manager 
Java Engineering Group 
brstaffo at microsoft.com 
Microsoft

> Thanks Michael, that's been a very useful suggestion. After I mailed,
> we discovered a VM that could repro the problem. This let us check the
> theory that it's FS virt related and indeed it is; disabling it fixes
> the issue. It is still worth working around it in the JVM because not
> everyone will see this thread and apps distributed via the MS Store
> using their standard instructions will hit it.
>
> To readers from the future! You have two ways to fix this if you're
> using a JVM/Windows build with the issue. One way is to add the
> following to the appropriate sections of your appx manifest:
>
> <Properties>
>   <virtualization:FileSystemWriteVirtualization>
>     <virtualization:ExcludedDirectories>
>       <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Temp\JavaSockets</virtualization:ExcludedDirectory>
>     </virtualization:ExcludedDirectories>
>   </virtualization:FileSystemWriteVirtualization>
> </Properties>
> <Capabilities>
>   <rescap:Capability Name="unvirtualizedResources" />
> </Capabilities>
>
> and then on Windows set the system property jdk.net.unixdomain.tmpdir
> = "%LOCALAPPDATA%/Temp/JavaSockets"
>
> Or a better way, head over to https://hydraulic.software/ and download
> Conveyor which works around this bug and (sadly) several other Windows
> bugs for you.






From duke at openjdk.org  Sun Mar 12 16:31:39 2023
From: duke at openjdk.org (Markus KARG)
Date: Sun, 12 Mar 2023 16:31:39 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v19]
In-Reply-To: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
Message-ID: <z_gEk-e1PRI4QAIUxJFgsUG6We97hTmjOf2EOAcWuDQ=.f7ba17ee-8842-403d-b726-9f2068301b71@github.com>

> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.

Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - updated copyright
 - Implementing 8278268
   
   Signed-off-by: Markus Karg <markus at headcrashing.eu>

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

Changes: https://git.openjdk.org/jdk/pull/6711/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=6711&range=18
  Stats: 806 lines in 6 files changed: 574 ins; 199 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/6711.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/6711/head:pull/6711

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

From duke at openjdk.org  Sun Mar 12 16:31:40 2023
From: duke at openjdk.org (Markus KARG)
Date: Sun, 12 Mar 2023 16:31:40 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v18]
In-Reply-To: <iZi7DBs0uY5MJSH0N1quXHnuQ2aWxhf3icpcFNET9Uc=.4135cc6e-057b-4cc1-9ab0-73d46c5b2de6@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <zeqPFFObcVGQrMGMWcZfBfFbWf9H_LSskwcQOvD1x9I=.28fb1844-c14e-4b44-a409-711d41f7e595@github.com>
 <iZi7DBs0uY5MJSH0N1quXHnuQ2aWxhf3icpcFNET9Uc=.4135cc6e-057b-4cc1-9ab0-73d46c5b2de6@github.com>
Message-ID: <fnqhurH6WDOB-sp2rSLStc3EldA7ut4_cYQ-lj0JZ6Q=.d2f5f157-9d1c-4c36-b4aa-574ec561ba30@github.com>

On Tue, 28 Feb 2023 23:49:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Before anything else, you might consider merging the current master into your branch. Aside from the copyright year change of the most recent commit, the branch is over two and a half months out of date.

I have rebased this PR branch ontop of the current master branch, so it is up-to-date-now.

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

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

From duke at openjdk.org  Sun Mar 12 17:04:28 2023
From: duke at openjdk.org (Markus KARG)
Date: Sun, 12 Mar 2023 17:04:28 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v18]
In-Reply-To: <mlEXMZ3Pqw0doGNhZqe2xV0tDCgGqHt3OigoWbuKAKE=.5e20ac0a-ed95-45a8-9d39-83fc21528b2a@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <zeqPFFObcVGQrMGMWcZfBfFbWf9H_LSskwcQOvD1x9I=.28fb1844-c14e-4b44-a409-711d41f7e595@github.com>
 <mlEXMZ3Pqw0doGNhZqe2xV0tDCgGqHt3OigoWbuKAKE=.5e20ac0a-ed95-45a8-9d39-83fc21528b2a@github.com>
Message-ID: <JkIhCpnhj8vGfiah8I1A7tM8VcvkEn6VzVKLLmTJflI=.27d6d6e9-ad09-49b6-b387-82967c2ace73@github.com>

On Wed, 1 Mar 2023 01:37:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> In the test classes `TransferTo` and `TransferTo2`, the methods `testNullPointerException` and `testStreamContents` are identical aside from expecting different `DataProvider`s. The contents of the methods could be abstracted out to common methods called by different `Test`s which expect different `DataProvider`s.
> 
> The test classes `TransferTo_2GB_transferFrom` and `TransferTo_2GB_transferTo` comprise roughly 120 lines of code each, but a diff of their contents reveals little in the way of substantive differences aside from jtreg tags, comments, and names:
> 
> 96,99c95,97
> <                 // performing actual transfer, effectively by multiple invocations of
> <                 // FileChannel.transferFrom(ReadableByteChannel)
> <                 try (InputStream inputStream = Channels.newInputStream(Channels.newChannel(
> <                         new BufferedInputStream(Files.newInputStream(sourceFile))));
> ---
>>                 // perform actual transfer, effectively by multiple invocations
>>                 // of FileChannel.transferTo(WritableByteChannel)
>>                 try (InputStream inputStream = Channels.newInputStream(FileChannel.open(sourceFile));
> 
> Perhaps something along these lines might work:
> * rename `TransferToBase` to for example to `TransferBase` or `TransferFromToBase`;
> * rename `TransferTo2` to `TransferFrom`;
> * rename `TransferTo_2GB_transferX` classes to `TransferX_2GB`;
> * refactor common code to `TransferBase` along the lines described above;
> * refactor child classes as needed to use the common code.
> 
> Assuming the foregoing makes sense, there would remain a total of four tests. It might be possible also to merge `TransferFrom` and `TransferTo` into a single test, but I think the two tests `*_2GB*` should remain separate as they likely each have a sufficiently long run time.

@bplb Before I stark to refactor anything, it makes sense to briefly discuss your recent proposal:
> In the test classes `TransferTo` and `TransferTo2`, the methods `testNullPointerException` and `testStreamContents` are identical aside from expecting different `DataProvider`s. The contents of the methods could be abstracted out to common methods called by different `Test`s which expect different `DataProvider`s.

This is correct and I have no objections to that, but on the other hand, there is no need to keep the separate `TransferTo2`  class separated, as the reason for the existence of `TransferTo2` was a bug somewhere else in OpenJDK that does not
exist anymore (for reference, the bug was in the Pipe implementation on Windows). Do that fact, Lance proposed to *merge* these files:
> I haven't gone through this in detail, but we want to merge The remaining TransferTo2 tests into TransferTo. 

So can you please briefly **confirm** that I *shall not* merge `TransferTo2` into `TransferTo` as *Lance* proposed (hence `TransferTo2` will not be a *separate* class anymore) but **instead** I *only shall* abstract `testNullPointerException` and `testStreamContents` as *you* proposed (hence keep `TransferTo2` as a *separate* class)? Thanks.

>...I think the two tests `*_2GB*` should remain separate as they likely each have a sufficiently long run time.

I confirm that we had intentionally kept these two tests in separate classes due to the long run time of each, so I agree to keep them *as separate* classes, but I will reduce *duplicate* code.

I need to mention that the **file names** *should not* be changed according to you proposed, as `*_transferFrom` is actually *not* testing the method `TransferFrom`, but it is testing the method `TransferTo`'s implementation which *internally uses* `transferFrom`. Hence it would be wrong w.r.t to the general test file naming convention to rename the test to `TransferFrom`. 

So can you please briefly **confirm** that I am correct with this objection and the 2GB files *should not* be renamed?

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

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

From djelinski at openjdk.org  Mon Mar 13 09:48:19 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 13 Mar 2023 09:48:19 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
 [v2]
In-Reply-To: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
Message-ID: <N29UzC6ui20HteGvW0po5IM6OZ0y2B6xTFwOxMo4rY4=.4bdd5e30-75f6-4f2e-b6ff-d51efbaeefab@github.com>

> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
> 
> Other changes include:
> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
> - `getLastErrorString` is no longer exported by libjava.
> 
> Tier1-3 tests continue to pass.
> 
> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.

Daniel Jeli?ski has updated the pull request incrementally with three additional commits since the last revision:

 - Address review comments
 - Mention that the returned text is static and thread safe
 - Define buffer size

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12922/files
  - new: https://git.openjdk.org/jdk/pull/12922/files/8ab8d729..ea91b651

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

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

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

From djelinski at openjdk.org  Mon Mar 13 09:48:22 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 13 Mar 2023 09:48:22 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
 [v2]
In-Reply-To: <gS2hCnJ8ArwPZ1ew9Q2qrzJShiTmEtFuMRiJzGknSXc=.884e89eb-37cd-4fbc-a04b-b58c9ef2a69f@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
 <gS2hCnJ8ArwPZ1ew9Q2qrzJShiTmEtFuMRiJzGknSXc=.884e89eb-37cd-4fbc-a04b-b58c9ef2a69f@github.com>
Message-ID: <tP59OKd5vSApP2SM6O-RVcdtZI1b2NhKH42V-O1V_hI=.f993a69d-0642-4e07-bd63-01e1794b8a55@github.com>

On Fri, 10 Mar 2023 21:47:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Address review comments
>>  - Mention that the returned text is static and thread safe
>>  - Define buffer size
>
> src/java.base/share/native/libjava/jni_util.c line 133:
> 
>> 131:     if (s != NULL) {
>> 132:         jobject x = NULL;
>> 133:         if (messagelen) {
> 
> Avoid implicit compare with 0; use `messagelen > 0` or similar.

preexisting, but fixed.

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

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

From djelinski at openjdk.org  Mon Mar 13 09:48:27 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 13 Mar 2023 09:48:27 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
 [v2]
In-Reply-To: <AyPPlmMJpvB2-dbHUHKvD6czbC1o_7pnRFC3LJRw3nQ=.416fdc11-31d1-44a8-a950-697be52b4ec7@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
 <AyPPlmMJpvB2-dbHUHKvD6czbC1o_7pnRFC3LJRw3nQ=.416fdc11-31d1-44a8-a950-697be52b4ec7@github.com>
Message-ID: <IrtidimtLQXgzE4Xp78L6qs40l1vpRGc8qDVzU0k0wM=.e8985614-26f0-44ed-98e7-e995b69aebae@github.com>

On Thu, 9 Mar 2023 18:08:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Address review comments
>>  - Mention that the returned text is static and thread safe
>>  - Define buffer size
>
> src/java.base/share/native/libzip/zip_util.c line 767:
> 
>> 765:  * or NULL if an error occurred. If a zip error occurred then *pmsg will
>> 766:  * be set to the error message text if pmsg != 0. Otherwise, *pmsg will be
>> 767:  * set to NULL. Caller doesn't need to free the error message.
> 
> I'd put some more context here why the caller does not need to free. (as it is a static text)

Added; also mentioned that we want the buffer to be thread-safe. Let me know if that's what you had in mind.

> src/java.base/windows/native/libjava/jni_util_md.c line 80:
> 
>> 78:                 0,
>> 79:                 buf,
>> 80:                 sizeof(buf) / sizeof(WCHAR),
> 
> Maybe better to #define the size 256 so that this division is not needed.

done

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

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

From alanb at openjdk.org  Mon Mar 13 12:39:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Mar 2023 12:39:21 GMT
Subject: RFR: 8303934: (fc) Use splice in FileChannel::transferFrom when
 the source is a pipe (Linux)
In-Reply-To: <qjBAxvqqoexYZXsXchq4VKJAPZrVY7EWkfQXDV_nJrw=.644d2265-4a97-4e7c-b274-926bc729d159@github.com>
References: <qjBAxvqqoexYZXsXchq4VKJAPZrVY7EWkfQXDV_nJrw=.644d2265-4a97-4e7c-b274-926bc729d159@github.com>
Message-ID: <vpwYXQQ1iSm1eSSbMxyr0EJckUt9DjQe8Zx2ciEYV5Q=.bcc6cab2-a363-4ac1-92af-e37bebe8c8f5@github.com>

On Fri, 10 Mar 2023 00:35:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On Linux, perform `transferFrom()` via the `splice(2)` system call when the source `ReadableByteChannel` is a `Pipe.SourceChannel` (`sun.nio.ch.SourceChannelImpl`).

A concern with optimizations like this is that they don't coordinate with other methods on the source channel, in this case read and close. This goes for the optimizations in the transferTo implementation too.

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

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

From rriggs at openjdk.org  Mon Mar 13 15:10:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 13 Mar 2023 15:10:31 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
 [v2]
In-Reply-To: <N29UzC6ui20HteGvW0po5IM6OZ0y2B6xTFwOxMo4rY4=.4bdd5e30-75f6-4f2e-b6ff-d51efbaeefab@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
 <N29UzC6ui20HteGvW0po5IM6OZ0y2B6xTFwOxMo4rY4=.4bdd5e30-75f6-4f2e-b6ff-d51efbaeefab@github.com>
Message-ID: <88rPs699hRVHL_w1dIfbGgp5fhsoP9a4aTXqtuXZD8g=.1a441cba-0807-4de1-9174-92e2eeff3dad@github.com>

On Mon, 13 Mar 2023 09:48:19 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
>> 
>> Other changes include:
>> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
>> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
>> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
>> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
>> - `getLastErrorString` is no longer exported by libjava.
>> 
>> Tier1-3 tests continue to pass.
>> 
>> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
>> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.
>
> Daniel Jeli?ski has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Address review comments
>  - Mention that the returned text is static and thread safe
>  - Define buffer size

LGTM for some pre-existing code style inconsistencies.

src/java.base/share/native/libzip/zip_util.c line 812:

> 810: 
> 811:     if (strlen(name) >= PATH_MAX) {
> 812:         if (pmsg) {

Some pre-existing references to pmsg still use implicit comparison, though not material to this PR, can you update them to compare with NULL.

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

Marked as reviewed by rriggs (Reviewer).

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

From djelinski at openjdk.org  Mon Mar 13 15:55:27 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 13 Mar 2023 15:55:27 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
 [v3]
In-Reply-To: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
Message-ID: <NCVb1BAonQHJxY-ebs8vxR3Hy8h3PsAjeKkZ1E3FkPA=.87815c8d-2ca0-4b3f-b2a1-fa7d94c526cc@github.com>

> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
> 
> Other changes include:
> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
> - `getLastErrorString` is no longer exported by libjava.
> 
> Tier1-3 tests continue to pass.
> 
> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Use NULL where appropriate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12922/files
  - new: https://git.openjdk.org/jdk/pull/12922/files/ea91b651..efd72a1d

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

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

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

From djelinski at openjdk.org  Mon Mar 13 16:01:05 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 13 Mar 2023 16:01:05 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
 [v2]
In-Reply-To: <88rPs699hRVHL_w1dIfbGgp5fhsoP9a4aTXqtuXZD8g=.1a441cba-0807-4de1-9174-92e2eeff3dad@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
 <N29UzC6ui20HteGvW0po5IM6OZ0y2B6xTFwOxMo4rY4=.4bdd5e30-75f6-4f2e-b6ff-d51efbaeefab@github.com>
 <88rPs699hRVHL_w1dIfbGgp5fhsoP9a4aTXqtuXZD8g=.1a441cba-0807-4de1-9174-92e2eeff3dad@github.com>
Message-ID: <lHXynO3gxN7tWNYzxzDnDGm_nTxhpPC6v_9AR0sULn8=.f33988ea-2536-40a1-8cbb-bd50be1b1231@github.com>

On Mon, 13 Mar 2023 15:05:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Address review comments
>>  - Mention that the returned text is static and thread safe
>>  - Define buffer size
>
> src/java.base/share/native/libzip/zip_util.c line 812:
> 
>> 810: 
>> 811:     if (strlen(name) >= PATH_MAX) {
>> 812:         if (pmsg) {
> 
> Some pre-existing references to pmsg still use implicit comparison, though not material to this PR, can you update them to compare with NULL.

done.

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

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

From naoto at openjdk.org  Mon Mar 13 16:47:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Mar 2023 16:47:52 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
 [v3]
In-Reply-To: <NCVb1BAonQHJxY-ebs8vxR3Hy8h3PsAjeKkZ1E3FkPA=.87815c8d-2ca0-4b3f-b2a1-fa7d94c526cc@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
 <NCVb1BAonQHJxY-ebs8vxR3Hy8h3PsAjeKkZ1E3FkPA=.87815c8d-2ca0-4b3f-b2a1-fa7d94c526cc@github.com>
Message-ID: <Pnmn5qyc84rUyX6TG2NZoHcjPzS1CyOVULL1zomjhmk=.d28ab59c-8fda-4ee5-b987-679abf6c394d@github.com>

On Mon, 13 Mar 2023 15:55:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
>> 
>> Other changes include:
>> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
>> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
>> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
>> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
>> - `getLastErrorString` is no longer exported by libjava.
>> 
>> Tier1-3 tests continue to pass.
>> 
>> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
>> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use NULL where appropriate

Marked as reviewed by naoto (Reviewer).

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

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

From brian.burkhalter at oracle.com  Mon Mar 13 23:16:09 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 13 Mar 2023 23:16:09 +0000
Subject: String encoding to ByteBuffer
In-Reply-To: <1127337400.2205617.1677454797231@email.ionos.com>
References: <1127337400.2205617.1677454797231@email.ionos.com>
Message-ID: <82795151-C155-4D44-B875-E27F7E81E70C@oracle.com>

Redirecting to nio-dev which is the more appropriate forum for this topic.

> On Feb 26, 2023, at 3:39 PM, Carl M <java at rkive.org> wrote:
> 
> I'm looking into adding a fast path case for encoding Strings into ByteBuffers, and wanted to get feedback on a possible approach.  My use case is taking mostly-ASCII, UTF-8 Strings and writing them to the disk/network.  To do this today, there are two approaches which both have drawbacks:
> 
> 1.  Use String.getBytes(StandardCharsets.UTF_8), and call ByteBuffer.put().  The downside of this approach is that I need to make a copy of the String's byte[] value.    The upside of this approach is that ByteBuffer uses the intrinsic copy methods, which are fast.
> 
> 2.  Wrap the String in a CharBuffer, and call CharsetEncoder.encode(CharBuffer, ByteBuffer).  This avoids copying the String value.  However, when using the UTF_8 encoder, there is no fastpath for writing to direct ByteBuffers.   sun.nio.cs.UTF_8.encodeLoop() only has fast paths for when the destination is array based.  This allocates less memory, but is overall slower in my JMH benchmark.
> 
> To fix this, I looked at adding an overload to CharsetEncoder to accept a String (or a CharSequence), and a ByteBuffer as a destination.  However, this is not easily doable, since it's hard to call it in a loop.  In the case that the String overflows the BB, the caller needs to be able to provide a new BB and resume from where they left off.  The CharBuffer approach works here because it keeps the position last read, and can resume from there.  
> 
> To encode a String, we need to know that the character index written to resume with a larger buffer.  However, the return type on CharsetEncoder's encode method is a CoderResult.  The length() method on this can't be called for underflow cases.  This means that there isn't a usable return type here (neither int nor CoderResult can be used).
> 
> Another, almost-possible solution I was considering adding a special case to UTF_8 for direct buffer destinations, and a corresponding JLA.encodeASCII overload that accepts a ByteBuffer.  The challenge here is that a wrapped CharBuffer doesn't have an array, and so doesn't get the fast path copying.
> 
> The reason I am reaching out here is that I am looking for feedback on my analysis of the existing API.  I am wondering what API compromises could be made to fast path writing Strings to direct buffers, which I feel is probably a common operation.  The only reasonable way I can see to implement is a new return type, which also seems undesirable as well.
> 
> Carl


From djelinski at openjdk.org  Tue Mar 14 17:22:18 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 14 Mar 2023 17:22:18 GMT
Subject: Integrated: 8303814: getLastErrorString should avoid charset
 conversions
In-Reply-To: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
Message-ID: <aGzKnPoUNbNt8-Bi9yiaYaUH9Lb4Y6MuY2Eoh-xvQKA=.0e8b2e72-4ba9-4f35-b94b-0511a02c1ae1@github.com>

On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
> 
> Other changes include:
> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
> - `getLastErrorString` is no longer exported by libjava.
> 
> Tier1-3 tests continue to pass.
> 
> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.

This pull request has now been integrated.

Changeset: baf11e73
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/baf11e734f7b5308490edc74f3168744c0857b24
Stats:     151 lines in 8 files changed: 21 ins; 44 del; 86 mod

8303814: getLastErrorString should avoid charset conversions

Reviewed-by: naoto, cjplummer, rriggs

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

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

From jwaters at openjdk.org  Tue Mar 14 17:50:01 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 14 Mar 2023 17:50:01 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
 [v3]
In-Reply-To: <NCVb1BAonQHJxY-ebs8vxR3Hy8h3PsAjeKkZ1E3FkPA=.87815c8d-2ca0-4b3f-b2a1-fa7d94c526cc@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
 <NCVb1BAonQHJxY-ebs8vxR3Hy8h3PsAjeKkZ1E3FkPA=.87815c8d-2ca0-4b3f-b2a1-fa7d94c526cc@github.com>
Message-ID: <zlw0-VG0eIRQ7M3gQ9V1tJ5U8X2n6f3OCiOnQwZGf8Y=.420421b4-6dfd-4f27-8516-40e8d6c45080@github.com>

On Mon, 13 Mar 2023 15:55:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
>> 
>> Other changes include:
>> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
>> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
>> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
>> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
>> - `getLastErrorString` is no longer exported by libjava.
>> 
>> Tier1-3 tests continue to pass.
>> 
>> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
>> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use NULL where appropriate

The change in Windows behaviour seems like a worrying gotcha that someone using the method might be trapped by (C library errors and system errors are reported for Unix while only WINAPI is returned on Windows). Although this has already been pushed I'd still like to mention that me and Thomas did have quite a bit of discussion regarding the conundrum on Windows about whether to report both when the error routines are called or have separate methods/mechanism to select either, see [8292016](https://bugs.openjdk.org/browse/JDK-8292016?filter=-1)

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

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

From djelinski at openjdk.org  Tue Mar 14 18:20:17 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 14 Mar 2023 18:20:17 GMT
Subject: RFR: 8303814: getLastErrorString should avoid charset conversions
 [v3]
In-Reply-To: <NCVb1BAonQHJxY-ebs8vxR3Hy8h3PsAjeKkZ1E3FkPA=.87815c8d-2ca0-4b3f-b2a1-fa7d94c526cc@github.com>
References: <f7gdYyums1UWnuRF0GSsimCAcFaKc9yBxvPgpoTIf2I=.3234f17f-2ee2-4d85-a2e7-2deecf9ce7c7@github.com>
 <NCVb1BAonQHJxY-ebs8vxR3Hy8h3PsAjeKkZ1E3FkPA=.87815c8d-2ca0-4b3f-b2a1-fa7d94c526cc@github.com>
Message-ID: <OcvJoeZuGCdlQa4jg1nzbvF9zsCrk0fJzpKTKdkSdUc=.ef539ab9-5ddd-447c-b455-e897a49af289@github.com>

On Mon, 13 Mar 2023 15:55:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch modifies the `getLastErrorString` method to return a `jstring`. Thanks to that we can avoid unnecessary back and forth conversions between Unicode and other charsets on Windows.
>> 
>> Other changes include:
>> - the Windows implementation of `getLastErrorString` no longer checks `errno`. I verified all uses of the method and confirmed that `errno` is not used anywhere. 
>> - While at it, I found and fixed a few calls to `JNU_ThrowIOExceptionWithLastError` that were done in context where `LastError` was not set.
>> - jdk.hotspot.agent was modified to use `JNU_ThrowByNameWithLastError` and `JNU_ThrowByName` instead of `getLastErrorString`; the code is expected to have identical behavior.
>> - zip_util was modified to return static messages instead of generated ones. The generated messages were not observed anywhere, because they were replaced by a static message in ZIP_Open, which is the only method used by other native code.
>> - `getLastErrorString` is no longer exported by libjava.
>> 
>> Tier1-3 tests continue to pass.
>> 
>> No new automated regression test; testing this requires installing a language pack that cannot be displayed in the current code page.
>> Tested this manually by installing Chinese language pack on English Windows 11, selecting Chinese language, then checking if the message on exception thrown by `InetAddress.getByName("nonexistent.local");` starts with `"?????????"` (or `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the change, the exception message started with a row of question marks.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use NULL where appropriate

we never use any of the JNU_XXX functions to report errno on Windows as far as I could tell. And even if we did, we'd need to call SetLastError(0) before JNU_Throw to make it work, which we never did. I think we're ok here.

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

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

From bpb at openjdk.org  Wed Mar 15 21:49:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 15 Mar 2023 21:49:15 GMT
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support
 position > size() [v2]
In-Reply-To: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
References: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
Message-ID: <EBHr3_RZd_Y_Q7_gVYClTomkjBiNX9YU9t-ZO63b5AI=.d342a86e-0171-4d8d-b446-7a1e44594e64@github.com>

> Enhance `FileChannel::transferFrom` to extend the channel's file if `position > size()`. This is consistent with `FileChannel::write(ByteBuffer, long)`.

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

  8303260: Convert test to JUnit 5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12797/files
  - new: https://git.openjdk.org/jdk/pull/12797/files/82afccce..0639c239

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

  Stats: 91 lines in 1 file changed: 43 ins; 21 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/12797.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12797/head:pull/12797

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

From bpb at openjdk.org  Wed Mar 15 21:49:34 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 15 Mar 2023 21:49:34 GMT
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support
 position > size()
In-Reply-To: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
References: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
Message-ID: <BbrmOpP60sk3cXJbvxBFZsjPDxwQhx5N0gYlk8xRwi4=.a31bc88c-72b7-4760-ad9a-a6159986bdc1@github.com>

On Wed, 1 Mar 2023 01:34:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Enhance `FileChannel::transferFrom` to extend the channel's file if `position > size()`. This is consistent with `FileChannel::write(ByteBuffer, long)`.

> [M]aybe we just replace it (the test) with a simpler JUnit style test?

Addressed by 0639c2390e228f572c71a1642801033e7fc45222.

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

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

From duke at openjdk.org  Thu Mar 16 02:10:30 2023
From: duke at openjdk.org (JackyWoo)
Date: Thu, 16 Mar 2023 02:10:30 GMT
Subject: Withdrawn: 8303509: Socket setTrafficClass does not work for IPv4
 connections when IPv6 enabled
In-Reply-To: <ShHpGf8u5wgsB_CZLGxys5dF4eF18j-UiMqBnXqhuQc=.df882174-b36e-4cce-ac50-12a6c7dfd75b@github.com>
References: <ShHpGf8u5wgsB_CZLGxys5dF4eF18j-UiMqBnXqhuQc=.df882174-b36e-4cce-ac50-12a6c7dfd75b@github.com>
Message-ID: <pvYVFFSt4W6oE5-6Fm_ffgyNeceMWbquoXVggUpXUyY=.8625779c-3759-4c56-98d8-7b4ee16aa8be@github.com>

On Fri, 3 Mar 2023 10:36:45 GMT, JackyWoo <duke at openjdk.org> wrote:

> This pr try to fix [JDK-8303509](https://bugs.openjdk.org/browse/JDK-8303509): Socket setTrafficClass does not work for IPv4 connections when IPv6 enabled.
> 
> ### Change Log
> When setting traffic class with IPv6 enabled, also set to IPv4 family.

This pull request has been closed without being integrated.

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

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

From lancea at openjdk.org  Fri Mar 17 16:48:28 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 17 Mar 2023 16:48:28 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v4]
In-Reply-To: <UE1Ihj1cgnu2H0mbL2PID2wjvd8z378NqmL9h_gdMPw=.c6b8e321-44f6-4e81-aefb-3cad76481cf8@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <UE1Ihj1cgnu2H0mbL2PID2wjvd8z378NqmL9h_gdMPw=.c6b8e321-44f6-4e81-aefb-3cad76481cf8@github.com>
Message-ID: <--LXw0fy4u2KX4YqPmS4S4VlmXml9ocFFDBEM3pevNU=.f1879919-38d4-436a-a98d-b7f8dc9269dc@github.com>

On Sat, 11 Mar 2023 07:28:14 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
>> 
>> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
>> 
>> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
>> 
>> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   APPNOTE.txt actually specifies an 'unknown' tag, let's use that instead of 0x42

Thank you for your work here Eirik, I think we are close.

I think I would include an additional entry in the zip just as an extra sanity check that we can navigate an additional entry

It is also worth noting that the LOC will still contain an extra field with the unknown tag of 0x9902 while the CEN is being changed to use Zip64, 0x1

A few more minor comments below.

I ran the current version of the test and it runs quickly on all platforms via mach5

Best
Lance

test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 173:

> 171:             ByteBuffer buffer = ByteBuffer.wrap(zip64).order(ByteOrder.LITTLE_ENDIAN);
> 172:             buffer.putShort(UNKNOWN_TAG); // Opaque tag makes ZipEntry.setExtra ignore it
> 173:             buffer.putShort((short) (zip64.length - 2 * Short.BYTES)); // Data size

The length of the zip64 extra field is going to be 28.   I would suggest making this a bit clearer and adding a field/constant which is set to 28 for clarity to make it easier for those who might look at this code later

test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 218:

> 216: 
> 217:         // Update the Zip64 field with the real tag
> 218:         buffer.putShort((short) 0x1); //  Tag for Zip64

I would probably make 0x1 a constant like the unknown tag.

It would be good to beef up the comment as the byte array written by ZipEntry::setExtra is set to the unknown tag for the Tag and the length is set to 28 which includes all of the Zip64 extra fields

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

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

From bpb at openjdk.org  Fri Mar 17 17:01:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Mar 2023 17:01:02 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v19]
In-Reply-To: <z_gEk-e1PRI4QAIUxJFgsUG6We97hTmjOf2EOAcWuDQ=.f7ba17ee-8842-403d-b726-9f2068301b71@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <z_gEk-e1PRI4QAIUxJFgsUG6We97hTmjOf2EOAcWuDQ=.f7ba17ee-8842-403d-b726-9f2068301b71@github.com>
Message-ID: <ygISMhq8uaEeGaK_7m1g1hmfpmtudHyfRltdmWPCAF4=.741d5587-72f7-41b8-9a5d-a9cf5e105107@github.com>

On Sun, 12 Mar 2023 16:31:39 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.
>
> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - updated copyright
>  - Implementing 8278268
>    
>    Signed-off-by: Markus Karg <markus at headcrashing.eu>

> So can you please briefly **confirm** that I _shall not_ merge `TransferTo2` into `TransferTo` as _Lance_ proposed (hence `TransferTo2` will not be a _separate_ class anymore) but **instead** I _only shall_ abstract `testNullPointerException` and `testStreamContents` as _you_ proposed (hence keep `TransferTo2` as a _separate_ class)? Thanks.

That is fine for now. It will be possible to revisit merging at a later time if it appears reasonable.

> > ...I think the two tests `*_2GB*` should remain separate as they likely each have a sufficiently long run time.
> 
> I confirm that we had intentionally kept these two tests in separate classes due to the long run time of each, so I agree to keep them _as separate_ classes, but I will reduce _duplicate_ code.

Sounds good.

> So can you please briefly **confirm** that I am correct with this objection and the 2GB files _should not_ be renamed?

That is fine.

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

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

From duke at openjdk.org  Fri Mar 17 18:36:02 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 17 Mar 2023 18:36:02 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v5]
In-Reply-To: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
Message-ID: <atRspgxDij2Hrly7iXoMXq5nsYlPKYZF-9wAJUvsqmY=.9976e631-2fea-4216-acc2-5bededc9cfae@github.com>

> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
> 
> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
> 
> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
> 
> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.

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

  Add extra entry as a sanity check. Extract some constants for sizes and extract method makeOpaqueExtraField to allow some more in-depth commenting. Move extra field processing until after the LOC headers are written, such that this information only occurs in the CEN

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12979/files
  - new: https://git.openjdk.org/jdk/pull/12979/files/22eba5c3..2fc841df

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

  Stats: 72 lines in 1 file changed: 48 ins; 7 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/12979.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12979/head:pull/12979

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

From duke at openjdk.org  Fri Mar 17 19:26:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 17 Mar 2023 19:26:44 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v5]
In-Reply-To: <atRspgxDij2Hrly7iXoMXq5nsYlPKYZF-9wAJUvsqmY=.9976e631-2fea-4216-acc2-5bededc9cfae@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <atRspgxDij2Hrly7iXoMXq5nsYlPKYZF-9wAJUvsqmY=.9976e631-2fea-4216-acc2-5bededc9cfae@github.com>
Message-ID: <AAEH5cO4_x87N3MieNqO89d0ynI2BCy5nWSx1pezpZ8=.d06cd4ed-94b7-4372-a256-7fb46f071081@github.com>

On Fri, 17 Mar 2023 18:36:02 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
>> 
>> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
>> 
>> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
>> 
>> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add extra entry as a sanity check. Extract some constants for sizes and extract method makeOpaqueExtraField to allow some more in-depth commenting. Move extra field processing until after the LOC headers are written, such that this information only occurs in the CEN

I ran the latest version of the test against a reverted ZipFileSystem to confirmed that it still catches the regression it was made for.

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

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

From duke at openjdk.org  Fri Mar 17 19:26:42 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 17 Mar 2023 19:26:42 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v4]
In-Reply-To: <--LXw0fy4u2KX4YqPmS4S4VlmXml9ocFFDBEM3pevNU=.f1879919-38d4-436a-a98d-b7f8dc9269dc@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <UE1Ihj1cgnu2H0mbL2PID2wjvd8z378NqmL9h_gdMPw=.c6b8e321-44f6-4e81-aefb-3cad76481cf8@github.com>
 <--LXw0fy4u2KX4YqPmS4S4VlmXml9ocFFDBEM3pevNU=.f1879919-38d4-436a-a98d-b7f8dc9269dc@github.com>
Message-ID: <VZLjsCheKtnVIqwrbPFtUrJIF3_rUVlWRbn0bIFE3dU=.82bafbd1-e4a3-4044-85e9-3b14970552cd@github.com>

On Fri, 17 Mar 2023 16:45:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I think I would include an additional entry in the zip just as an extra sanity check that we can navigate an additional entry

Added an additional entry as suggested and checked that is was navigated.

> It is also worth noting that the LOC will still contain an extra field with the unknown tag of 0x9902 while the CEN is being changed to use Zip64, 0x1

This stray opaque extra field should not be any issue, but just in case, I moved the ZipFIle.setExtra until after the LOC is written, so now only the CEN will have the Zip64 extra field.

> The length of the zip64 extra field is going to be 28. I would suggest making this a bit clearer and adding a field/constant which is set to 28 for clarity to make it easier for those who might look at this code later

I believe this should be well-described now between the constants and the `makeOpaqueExtraField` method.

> I would probably make 0x1 a constant like the unknown tag.

Extracted a constant with a comment.

> It would be good to beef up the comment as the byte array written by ZipEntry::setExtra is set to the unknown tag for the Tag and the length is set to 28 which includes all of the Zip64 extra fields

Opted to extract a method?to create the opaque extra field since that allows for more comments and declutters the calling method.

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

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

From duke at openjdk.org  Fri Mar 17 19:32:58 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 17 Mar 2023 19:32:58 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v5]
In-Reply-To: <atRspgxDij2Hrly7iXoMXq5nsYlPKYZF-9wAJUvsqmY=.9976e631-2fea-4216-acc2-5bededc9cfae@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <atRspgxDij2Hrly7iXoMXq5nsYlPKYZF-9wAJUvsqmY=.9976e631-2fea-4216-acc2-5bededc9cfae@github.com>
Message-ID: <QjYGeOsEeyfV90mMoEXB6GWSHrmu1n6BrMmh6ItHpvw=.052b9915-8f40-417f-aedc-2ed1166011c1@github.com>

On Fri, 17 Mar 2023 18:36:02 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
>> 
>> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
>> 
>> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
>> 
>> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add extra entry as a sanity check. Extract some constants for sizes and extract method makeOpaqueExtraField to allow some more in-depth commenting. Move extra field processing until after the LOC headers are written, such that this information only occurs in the CEN

Something worth mentioning:

This test  currently does not check that the last modified time stamp is actually the one read from the LOC and not from the CEN. And there is a discrepancey here, `ZipFileSystem` reads it from the LOC, while `ZipFile` reads it from the CEN.

We could test this by setting different last modified timestamps in the LOC and CEN and use assertEquals to verify that the expected time stamp is parsed.

@LanceAndersen Do you think this is worth pursuing in this PR? I have a sketch ready, but I fear will clutter the test with too many concerns. Perhaps better to test in a separate test which could be independent from Zip64 and local header offset concerns?

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

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

From lance.andersen at oracle.com  Fri Mar 17 19:59:57 2023
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 17 Mar 2023 19:59:57 +0000
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v5]
In-Reply-To: <QjYGeOsEeyfV90mMoEXB6GWSHrmu1n6BrMmh6ItHpvw=.052b9915-8f40-417f-aedc-2ed1166011c1@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <atRspgxDij2Hrly7iXoMXq5nsYlPKYZF-9wAJUvsqmY=.9976e631-2fea-4216-acc2-5bededc9cfae@github.com>
 <QjYGeOsEeyfV90mMoEXB6GWSHrmu1n6BrMmh6ItHpvw=.052b9915-8f40-417f-aedc-2ed1166011c1@github.com>
Message-ID: <47649A02-DE4F-4C19-83B9-9D42123502E8@oracle.com>



On Mar 17, 2023, at 3:32 PM, Eirik Bjorsnos <duke at openjdk.org<mailto:duke at openjdk.org>> wrote:

On Fri, 17 Mar 2023 18:36:02 GMT, Eirik Bjorsnos <duke at openjdk.org<mailto:duke at openjdk.org>> wrote:

Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.

Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).

This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.

Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.

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

 Add extra entry as a sanity check. Extract some constants for sizes and extract method makeOpaqueExtraField to allow some more in-depth commenting. Move extra field processing until after the LOC headers are written, such that this information only occurs in the CEN

Something worth mentioning:

This test  currently does not check that the last modified time stamp is actually the one read from the LOC and not from the CEN. And there is a discrepancey here, `ZipFileSystem` reads it from the LOC, while `ZipFile` reads it from the CEN.

We could test this by setting different last modified timestamps in the LOC and CEN and use assertEquals to verify that the expected time stamp is parsed.

@LanceAndersen Do you think this is worth pursuing in this PR? I have a sketch ready, but I fear will clutter the test with too many concerns. Perhaps better to test in a separate test which could be independent from Zip64 and local header offset concerns?

Hi Eirik,

Please treat the timestamp issue above separately so we are not morphing issues.


Best
Lance

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

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

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]






Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230317/90f48398/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230317/90f48398/oracle_sig_logo.gif>

From duke at openjdk.org  Sat Mar 18 15:03:29 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 18 Mar 2023 15:03:29 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v20]
In-Reply-To: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
Message-ID: <6DitcTXBQwZGlxvPz0NXWo7CEFkrNcM0ysh54-dEPLA=.3f0a6692-d0d1-4854-9bc8-bc918af70f2c@github.com>

> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.

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

 - Abstracted assertStreamContents
 - Abstracted assertNullPointerException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/6711/files
  - new: https://git.openjdk.org/jdk/pull/6711/files/50146a9d..6d3e1835

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

  Stats: 114 lines in 3 files changed: 48 ins; 62 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/6711.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/6711/head:pull/6711

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

From duke at openjdk.org  Sat Mar 18 16:35:15 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 18 Mar 2023 16:35:15 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v21]
In-Reply-To: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
Message-ID: <cZUqlMDfHxytpHyVR56ywnxZA_7pEdogM_k2XJz1swM=.2709b5ba-60d9-455e-a2d6-dd28c97606e2@github.com>

> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.

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

  Abstracted testMoreThanTwoGB

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/6711/files
  - new: https://git.openjdk.org/jdk/pull/6711/files/6d3e1835..fb198503

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

  Stats: 187 lines in 3 files changed: 68 ins; 77 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/6711.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/6711/head:pull/6711

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

From duke at openjdk.org  Sat Mar 18 16:35:17 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 18 Mar 2023 16:35:17 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v19]
In-Reply-To: <ygISMhq8uaEeGaK_7m1g1hmfpmtudHyfRltdmWPCAF4=.741d5587-72f7-41b8-9a5d-a9cf5e105107@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <z_gEk-e1PRI4QAIUxJFgsUG6We97hTmjOf2EOAcWuDQ=.f7ba17ee-8842-403d-b726-9f2068301b71@github.com>
 <ygISMhq8uaEeGaK_7m1g1hmfpmtudHyfRltdmWPCAF4=.741d5587-72f7-41b8-9a5d-a9cf5e105107@github.com>
Message-ID: <8fn-fpHeShp4CQ0O1KNDaNiUsmCivncoOunvwVL7Y2o=.5c564bf5-8207-4e9a-bd14-b620ceb298b8@github.com>

On Fri, 17 Mar 2023 16:58:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - updated copyright
>>  - Implementing 8278268
>>    
>>    Signed-off-by: Markus Karg <markus at headcrashing.eu>
>
>> So can you please briefly **confirm** that I _shall not_ merge `TransferTo2` into `TransferTo` as _Lance_ proposed (hence `TransferTo2` will not be a _separate_ class anymore) but **instead** I _only shall_ abstract `testNullPointerException` and `testStreamContents` as _you_ proposed (hence keep `TransferTo2` as a _separate_ class)? Thanks.
> 
> That is fine for now. It will be possible to revisit merging at a later time if it appears reasonable.
> 
>> > ...I think the two tests `*_2GB*` should remain separate as they likely each have a sufficiently long run time.
>> 
>> I confirm that we had intentionally kept these two tests in separate classes due to the long run time of each, so I agree to keep them _as separate_ classes, but I will reduce _duplicate_ code.
> 
> Sounds good.
> 
>> So can you please briefly **confirm** that I am correct with this objection and the 2GB files _should not_ be renamed?
> 
> That is fine.

@bplb I am done with the requested changes. There is no duplicated code anymore. :-)

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

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

From alanb at openjdk.org  Sun Mar 19 19:04:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 Mar 2023 19:04:22 GMT
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support
 position > size() [v2]
In-Reply-To: <EBHr3_RZd_Y_Q7_gVYClTomkjBiNX9YU9t-ZO63b5AI=.d342a86e-0171-4d8d-b446-7a1e44594e64@github.com>
References: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
 <EBHr3_RZd_Y_Q7_gVYClTomkjBiNX9YU9t-ZO63b5AI=.d342a86e-0171-4d8d-b446-7a1e44594e64@github.com>
Message-ID: <JEfppLbz0SkueDreWkcpht66JSb32k_XXozFaBaTxVo=.d917ae8e-10ec-4d2f-9420-e0d6cc34638f@github.com>

On Wed, 15 Mar 2023 21:49:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Enhance `FileChannel::transferFrom` to extend the channel's file if `position > size()`. This is consistent with `FileChannel::write(ByteBuffer, long)`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303260: Convert test to JUnit 5

test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 98:

> 96:     @MethodSource("fastParamProvider")
> 97:     void fromFast(long initialPosition, int bufSize, long offset)
> 98:         throws IOException {

Aligning the "throws IOException {" with the method body makes it hard to read, can you move this to the previous line?

test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 104:

> 102:             byte[] bytes = new byte[bufSize];
> 103:             RND.nextBytes(bytes);
> 104:             src.write(ByteBuffer.wrap(bytes), 0);

Return value from write probably needs to be checked as a short write is possible in some cases.

test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 115:

> 113:     @ParameterizedTest
> 114:     @MethodSource("slowParamProvider")
> 115:     void fromSlow(long initialPosition, int bufSize, long offset)

A suggestion here is to rename this to fromReadingByteChannel to make a bit clearer.

test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 135:

> 133:      *
> 134:      * @throws RuntimeException if an unexpected number of bytes is transferred
> 135:      *                          or the transferred values are not as expected

This is a JUnit tests so I assume it should use the assertXXX methods rather than throwing RuntimeException.

test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 144:

> 142:                                                    READ, WRITE)) {
> 143:             target.position(initialPos);
> 144:             target.write(ByteBuffer.wrap(new byte[] {(byte)42}));

I assume you should assertEquals that write return 1 here.

test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 149:

> 147:             long transferred = target.transferFrom(src, position, count);
> 148:             if (transferred != count)
> 149:                 throw new RuntimeException(transferred + " != " + count);

transferFrom is allowed to return a result < count. There are cases where this can happen in the JDK implementation so I think you just want to check that transferred > 0 and that compare that portion of the file, right?

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

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

From bpb at openjdk.org  Mon Mar 20 16:48:17 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 20 Mar 2023 16:48:17 GMT
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support
 position > size() [v2]
In-Reply-To: <JEfppLbz0SkueDreWkcpht66JSb32k_XXozFaBaTxVo=.d917ae8e-10ec-4d2f-9420-e0d6cc34638f@github.com>
References: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
 <EBHr3_RZd_Y_Q7_gVYClTomkjBiNX9YU9t-ZO63b5AI=.d342a86e-0171-4d8d-b446-7a1e44594e64@github.com>
 <JEfppLbz0SkueDreWkcpht66JSb32k_XXozFaBaTxVo=.d917ae8e-10ec-4d2f-9420-e0d6cc34638f@github.com>
Message-ID: <MVcUDU8Q_E3DILg4E-Dc_hdwpW4Wq5YGn8K3sQh05-A=.fa733de5-17c1-4678-b5e0-179abd4ca0cd@github.com>

On Sun, 19 Mar 2023 07:30:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303260: Convert test to JUnit 5
>
> test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 98:
> 
>> 96:     @MethodSource("fastParamProvider")
>> 97:     void fromFast(long initialPosition, int bufSize, long offset)
>> 98:         throws IOException {
> 
> Aligning the "throws IOException {" with the method body makes it hard to read, can you move this to the previous line?

Changed in 085746fa9e7446c380ed08c951e52796915c1f53.

> test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 104:
> 
>> 102:             byte[] bytes = new byte[bufSize];
>> 103:             RND.nextBytes(bytes);
>> 104:             src.write(ByteBuffer.wrap(bytes), 0);
> 
> Return value from write probably needs to be checked as a short write is possible in some cases.

Changed in 085746fa9e7446c380ed08c951e52796915c1f53.

> test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 115:
> 
>> 113:     @ParameterizedTest
>> 114:     @MethodSource("slowParamProvider")
>> 115:     void fromSlow(long initialPosition, int bufSize, long offset)
> 
> A suggestion here is to rename this to fromReadingByteChannel to make a bit clearer.

Changed in 085746fa9e7446c380ed08c951e52796915c1f53.

> test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 135:
> 
>> 133:      *
>> 134:      * @throws RuntimeException if an unexpected number of bytes is transferred
>> 135:      *                          or the transferred values are not as expected
> 
> This is a JUnit tests so I assume it should use the assertXXX methods rather than throwing RuntimeException.

Changed in 085746fa9e7446c380ed08c951e52796915c1f53.

> test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 144:
> 
>> 142:                                                    READ, WRITE)) {
>> 143:             target.position(initialPos);
>> 144:             target.write(ByteBuffer.wrap(new byte[] {(byte)42}));
> 
> I assume you should assertEquals that write return 1 here.

So changed in 085746fa9e7446c380ed08c951e52796915c1f53.

> test/jdk/java/nio/channels/FileChannel/TransferFromExtend.java line 149:
> 
>> 147:             long transferred = target.transferFrom(src, position, count);
>> 148:             if (transferred != count)
>> 149:                 throw new RuntimeException(transferred + " != " + count);
> 
> transferFrom is allowed to return a result < count. There are cases where this can happen in the JDK implementation so I think you just want to check that transferred > 0 and that compare that portion of the file, right?

Changed in 085746fa9e7446c380ed08c951e52796915c1f53.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12797#discussion_r1142409486
PR Review Comment: https://git.openjdk.org/jdk/pull/12797#discussion_r1142409943
PR Review Comment: https://git.openjdk.org/jdk/pull/12797#discussion_r1142409776
PR Review Comment: https://git.openjdk.org/jdk/pull/12797#discussion_r1142408864
PR Review Comment: https://git.openjdk.org/jdk/pull/12797#discussion_r1142408599
PR Review Comment: https://git.openjdk.org/jdk/pull/12797#discussion_r1142409228

From bpb at openjdk.org  Mon Mar 20 16:47:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 20 Mar 2023 16:47:06 GMT
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support
 position > size() [v3]
In-Reply-To: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
References: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
Message-ID: <rwXTNCYBo7D5Sfir39Ksdy2UMXIhUj94bX-nroR0_z0=.67765b4a-9c74-489a-b8f3-1d07523c2c7a@github.com>

> Enhance `FileChannel::transferFrom` to extend the channel's file if `position > size()`. This is consistent with `FileChannel::write(ByteBuffer, long)`.

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

  8303260: Address reviewer comments on test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12797/files
  - new: https://git.openjdk.org/jdk/pull/12797/files/0639c239..085746fa

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

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

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

From pminborg at openjdk.org  Mon Mar 20 18:12:39 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 20 Mar 2023 18:12:39 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API (Third
 Preview)
Message-ID: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>

API changes for the FFM API (third preview)

Specdiff:
https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html

Javadoc:
https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

Commit messages:
 - Update after first round of comments
 - Remove extra line
 - Remove Panama-specific content
 - Generate delta

Changes: https://git.openjdk.org/jdk/pull/13079/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304265
  Stats: 13601 lines in 269 files changed: 5644 ins; 5999 del; 1958 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

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

From mcimadamore at openjdk.org  Mon Mar 20 18:12:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 20 Mar 2023 18:12:41 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <fVcrQYA7PJgeLbO_obZu4dnNiExgkWnNEcV-sVBP7I8=.276d4112-d943-4952-8ae0-6cee419cec3f@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Here are the main API changes introduced in this round:

* `SegmentScope` has been simplified into a pure lifetime abstraction and moved into a nested class `MemorySegment.Scope`. All segments have a scope (e.g. the segment lifetime), which is usually the scope of some `Arena`. All the factory methods in `SegmentScope` to create non-closeable lifetimes have been moved to `Arena` (e.g. `Arena.ofAuto` and `Arena.global`). This leads to a simplified API, which still allows to build custom arenas via simple delegation, but, at the same time, allows clients to use arenas with minimal indirections (e.g. `arena.scope()` is no longer needed in many places). Some factory names in `Arena` were also updated (e.g. from `openConfined` to `ofConfined`).
* `ValueLayout::OfAddress` has been moved to a toplevel class `AddressLayout`. Also, the method to obtain an address layout of unbounded size (`OfAddress::asUnbounded`) has been changed, so that it now takes the layout of the target region of memory pointed to by the address (`AddressLayout::withTargetLayout`).
* A new *layout path* is provided to dereference an address layout. This allows memory segment var handle to deal with complex dereference expressions like `*(a[10].x).y`.
* A new linker implementation, namely the *fallback linker* has been added. This linker is based on `libffi` and provides a very easy way to add support for `Linker` API, even in platforms that have limited functionalities (such as [zero](https://openjdk.org/projects/zero/)).
* The `VaList` interface has been dropped. Unfortunately, the behavior of `va_list` is hopelessly platform specific, and we could also never make full use of it in the `jextract` tool, given that parsing support `va_list` is very limited in `libclang`.
* The API for unsafely attaching spatial/temporal bounds to an unsafe memory segment has been improved and streamlined. The `MemorySegment::ofAddress` method is now a single, unrestricted method which turns a long address into a native memory segment whose base address is the provided address. The returned segment has a scope that is always alive, and has zero-length. To resize, or add new temporal bounds to an existing segments, clients can use the new `MemorySegment::reinterpret` methods. The logic for attaching a cleanup action to a memory segment has also been updated: now the cleanup action will take as input a shallow copy of the memory segment, in a scope that is always alive, so that clients can pass that copy to other functions in order to perform custom cleanup.
* We have made some changes and simplfications to the way in which runtime values such as `errno` are preserved, The `CapturedCallState` interface has been removed. Instead, there is a way to obtain a group layout of all the values that can be saved, given the platform in which the linker runs. Clients can query the layout, e.g. obtaining names for the values to be saved, and then create a linker option which lists all the name of the values to be saved.
* We have added support for *trivial* (or *leaf*) calls - that is native calls whose execution completes very quickly. This option might be useful when calling functions whose total execution time is comparable to that of the overhead of the change of the thread state from Java to native (in JNI, such calls are handled using *critical JNI*).

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

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1476648707

From duke at openjdk.org  Mon Mar 20 18:12:45 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 Mar 2023 18:12:45 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <aX3XPMUafkH6uFyRGKikJIbDHFHwAsGxIk0c8q8zHTw=.73a977b6-373b-48a6-982d-1d6ae5e303b3@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/AddressLayout.java line 59:

> 57:  */
> 58: @PreviewFeature(feature = PreviewFeature.Feature.FOREIGN)
> 59: sealed public interface AddressLayout extends ValueLayout permits ValueLayouts.OfAddressImpl {

This should?match other sealed?interfaces:
Suggestion:

public sealed interface AddressLayout extends ValueLayout permits ValueLayouts.OfAddressImpl {

src/java.base/share/classes/java/lang/foreign/Linker.java line 578:

> 576:          * Execution state is captured by a downcall method handle on invocation, by writing it
> 577:          * to a native segment provided by the user to the downcall method handle.
> 578:          * For this purpose, a downcall method handle linked with the this

Suggestion:

         * For this purpose, a downcall method handle linked with this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1140677384
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1140679387

From erikj at openjdk.org  Mon Mar 20 19:32:31 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 20 Mar 2023 19:32:31 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <t3FglkH9K_-puYnWMuRn84ohm2p3ewd-y31I9sSDHOI=.63c8f24b-7dc4-42f4-bea4-8ab078c99828@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Build changes look ok.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13079#pullrequestreview-1349265135

From bpb at openjdk.org  Mon Mar 20 21:03:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 20 Mar 2023 21:03:56 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v21]
In-Reply-To: <cZUqlMDfHxytpHyVR56ywnxZA_7pEdogM_k2XJz1swM=.2709b5ba-60d9-455e-a2d6-dd28c97606e2@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <cZUqlMDfHxytpHyVR56ywnxZA_7pEdogM_k2XJz1swM=.2709b5ba-60d9-455e-a2d6-dd28c97606e2@github.com>
Message-ID: <4J5-MPn4DiG3ZB4rDGy9725Qb7VrqQJIjb-mW7cI520=.c75c7030-834c-4ed4-93b0-03bb18231785@github.com>

On Sat, 18 Mar 2023 16:35:15 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Abstracted testMoreThanTwoGB

test/jdk/java/nio/channels/Channels/TransferToBase.java line 222:

> 220:                         byte[] rndBytes = createRandomBytes(BYTES_PER_WRITE, 0);
> 221:                         ByteBuffer src = ByteBuffer.wrap(rndBytes);
> 222:                         fc.write(src);

Should this code perhaps allow for a short write, i.e., `FileChannel::write` returning a value less than `rndBytes.length`? For example, something like this:

                    long pos = initPos;
                    while (pos < BYTES_WRITTEN) {
                        int len = Math.toIntExact(BYTES_WRITTEN - pos);
                        if (len > BYTES_PER_WRITE)
                            len = BYTES_PER_WRITE;
                        byte[] rndBytes = createRandomBytes(len, 0);
                        ByteBuffer src = ByteBuffer.wrap(rndBytes);
                        pos += fc.write(src);
                    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/6711#discussion_r1142672553

From psandoz at openjdk.org  Mon Mar 20 23:33:41 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 20 Mar 2023 23:33:41 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <ug6HcErmTSjZeFYe6EoeGyuSJ2dLVxNV95G65Pb-FC8=.62fb7b7d-d1f2-4b29-b713-d132824f7532@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/AddressLayout.java line 93:

> 91:      * @apiNote
> 92:      * This method can also be used to create an address layout which, when used, creates native memory
> 93:      * segments with maximal size (e.g. {@linkplain Long#MAX_VALUE}. This can be done by using a target sequence

Suggestion:

     * segments with maximal size (e.g. {@linkplain Long#MAX_VALUE}). This can be done by using a target sequence

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142769618

From psandoz at openjdk.org  Tue Mar 21 00:38:49 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 00:38:49 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <CCPgjTt6bNAY1NW-HJ0yGb1POVkZZED5ifgZNhSWZfQ=.871126a2-d21f-4a91-a271-eaf9cb729a13@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/Linker.java line 479:

> 477:      *     Otherwise, the invocation throws {@link WrongThreadException}; and</li>
> 478:      *     <li>{@code A} is kept alive during the invocation. For instance, if {@code A} has been obtained using a
> 479:      *     {@linkplain Arena#ofConfined() confined arena}, any attempt to {@linkplain Arena#close() close}

Is that correct? Do you mean a shared arena?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142798464

From psandoz at openjdk.org  Tue Mar 21 00:57:17 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 00:57:17 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/Linker.java line 609:

> 607:          * @see #captureStateLayout()
> 608:          */
> 609:         static Option captureCallState(String... capturedState) {

What if a name is not recognized? Throw IAE?

src/java.base/share/classes/java/lang/foreign/Linker.java line 621:

> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
> 620:          *
> 621:          * @see #captureCallState(String...)

How does a caller know what the structure may contain? Should we document the platform specific structures?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142804110
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142804836

From psandoz at openjdk.org  Tue Mar 21 01:17:42 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 01:17:42 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <gCw0GLdbWhEDntbtJ2vbG05KDkdF0PJFr0ujRDwE1E0=.e75212f0-b15d-4f7b-813e-2d2831a02d57@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 56:

> 54:  *     <li>It can be passed to an existing {@linkplain Linker#downcallHandle(FunctionDescriptor, Linker.Option...) downcall method handle}, as an argument to the underlying foreign function.</li>
> 55:  *     <li>It can be {@linkplain MemorySegment#set(AddressLayout, long, MemorySegment) stored} inside another memory segment.</li>
> 56:  *     <li>It can be used to access the region of memory backing a global variable (this might require

Suggestion:

 *     <li>It can be used to access the region of memory backing a global variable (this requires

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142812300

From pminborg at openjdk.org  Tue Mar 21 07:50:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 07:50:22 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v2]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <szmGqTNbFntO4asM1v1fdufExyMO2FY89WU5j5NrpeM=.1b6055f9-87e4-4c4f-a95a-7abe306a7c50@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update src/java.base/share/classes/java/lang/foreign/AddressLayout.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/bb2f4438..7a78948a

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

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

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

From pminborg at openjdk.org  Tue Mar 21 08:04:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 08:04:25 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v3]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <FGRSvA90xZez_v3fRQzgn7YqqYgHBK-0aiJr9UqWRJo=.40e2226e-3ee7-4981-a468-c71f25adf6ff@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

  Remove MemoryInspection classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/7a78948a..a71518c4

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

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

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

From pminborg at openjdk.org  Tue Mar 21 08:33:26 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 08:33:26 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v4]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <_HwSyb1bsHNIJpGKdznMZR_HfWIU9VeAl1etn4miKGQ=.8397676f-1e24-4a2e-bcfa-ed44fb8a515b@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

  Improve Linker javadocs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/a71518c4..4626a54e

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

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

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

From pminborg at openjdk.org  Tue Mar 21 08:33:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 08:33:29 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v4]
In-Reply-To: <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
Message-ID: <TbBkOj-wFsuDfnzM3HnB-BMxD87f5DXaf0mFmcUqCB0=.23850e94-11ae-430b-962a-2c308fc08aa9@github.com>

On Tue, 21 Mar 2023 00:52:01 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve Linker javadocs
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 609:
> 
>> 607:          * @see #captureStateLayout()
>> 608:          */
>> 609:         static Option captureCallState(String... capturedState) {
> 
> What if a name is not recognized? Throw IAE?

Added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143024389

From pminborg at openjdk.org  Tue Mar 21 09:02:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 09:02:29 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

  Add example for Option::captureStateLayout

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/4626a54e..21ef0607

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

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

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

From pminborg at openjdk.org  Tue Mar 21 09:02:33 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 09:02:33 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
Message-ID: <lphoedvalFnqUzhydGb-ggq1yG1UpsZMZvaswVJTiYc=.4a1d0cac-a88b-4600-8531-643b7a2b25fb@github.com>

On Tue, 21 Mar 2023 00:54:10 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
> 
>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>> 620:          *
>> 621:          * @see #captureCallState(String...)
> 
> How does a caller know what the structure may contain? Should we document the platform specific structures?

I've added an example of how to print the platform-dependent structure. Should we document anyhow?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143055969

From stsypanov at openjdk.org  Tue Mar 21 09:07:59 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 21 Mar 2023 09:07:59 GMT
Subject: RFR: 8304591: UnixPath.stringValue shouldn't be volatile
Message-ID: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>

`UnixPath.stringValue` can be computed by multiple threads safely as the actual value is the same, so the race is benign in this case.

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

Commit messages:
 - Fix build
 - UnixPath.stringValue shouldn't be volatile

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

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

From alanb at openjdk.org  Tue Mar 21 09:11:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Mar 2023 09:11:56 GMT
Subject: RFR: 8304591: UnixPath.stringValue shouldn't be volatile
In-Reply-To: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
References: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
Message-ID: <Rhd9e1evuYxOo8I1pNuE6c3SgKGTgQmLRgCM9jMv33M=.9abd0b88-2f3c-4b4e-a9dc-6e2d4e2eb803@github.com>

On Tue, 21 Mar 2023 09:00:19 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> `UnixPath.stringValue` can be computed by multiple threads safely as the actual value is the same, so the race is benign in this case.

Can you rename this PR to align with the JBS issue?

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

> 46: import static sun.nio.fs.UnixConstants.O_RDONLY;
> 47: import static sun.nio.fs.UnixNativeDispatcher.open;
> 48: import static sun.nio.fs.UnixNativeDispatcher.realpath;

Please revert this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/13115#issuecomment-1477489271
PR Review Comment: https://git.openjdk.org/jdk/pull/13115#discussion_r1143068235

From stsypanov at openjdk.org  Tue Mar 21 09:27:17 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 21 Mar 2023 09:27:17 GMT
Subject: RFR: 8304591: (fs) UnixPath.stringValue need not be volatile [v2]
In-Reply-To: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
References: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
Message-ID: <Anj1GDgwgRPHifuV2ilZYdaXD2xeai0GZ06MV-6ty70=.ec6ed3bc-e73f-4c33-8de5-2e2b4361e2b4@github.com>

> `UnixPath.stringValue` can be computed by multiple threads safely as the actual value is the same, so the race is benign in this case.

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

  Revert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13115/files
  - new: https://git.openjdk.org/jdk/pull/13115/files/2cc5ee57..88cd6cfc

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

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

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

From stsypanov at openjdk.org  Tue Mar 21 09:27:18 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 21 Mar 2023 09:27:18 GMT
Subject: RFR: 8304591: (fs) UnixPath.stringValue need not be volatile
In-Reply-To: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
References: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
Message-ID: <TiZcuIexQ1est9U2Wo6Vcwa6tXYf2QxJB9hVSfIgQKs=.ff6ca006-55ad-444d-ae1b-10688d8d33b5@github.com>

On Tue, 21 Mar 2023 09:00:19 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> `UnixPath.stringValue` can be computed by multiple threads safely as the actual value is the same, so the race is benign in this case.

Renamed

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

PR Comment: https://git.openjdk.org/jdk/pull/13115#issuecomment-1477503987

From stsypanov at openjdk.org  Tue Mar 21 09:27:18 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 21 Mar 2023 09:27:18 GMT
Subject: RFR: 8304591: (fs) UnixPath.stringValue need not be volatile [v2]
In-Reply-To: <Rhd9e1evuYxOo8I1pNuE6c3SgKGTgQmLRgCM9jMv33M=.9abd0b88-2f3c-4b4e-a9dc-6e2d4e2eb803@github.com>
References: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
 <Rhd9e1evuYxOo8I1pNuE6c3SgKGTgQmLRgCM9jMv33M=.9abd0b88-2f3c-4b4e-a9dc-6e2d4e2eb803@github.com>
Message-ID: <rH3bIBSsVo4IJ3M4mdXrXsdfC2zEKxzb0GzMLMKvn7s=.f75d8f13-b2d9-4675-9f41-1ac0957df79d@github.com>

On Tue, 21 Mar 2023 09:08:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert
>
> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 48:
> 
>> 46: import static sun.nio.fs.UnixConstants.O_RDONLY;
>> 47: import static sun.nio.fs.UnixNativeDispatcher.open;
>> 48: import static sun.nio.fs.UnixNativeDispatcher.realpath;
> 
> Please revert this change.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13115#discussion_r1143084473

From mcimadamore at openjdk.org  Tue Mar 21 09:52:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 09:52:54 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <CCPgjTt6bNAY1NW-HJ0yGb1POVkZZED5ifgZNhSWZfQ=.871126a2-d21f-4a91-a271-eaf9cb729a13@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <CCPgjTt6bNAY1NW-HJ0yGb1POVkZZED5ifgZNhSWZfQ=.871126a2-d21f-4a91-a271-eaf9cb729a13@github.com>
Message-ID: <Flvw3B4SJ83X49JboIaHlB2Qr20_16FfdgadeAB7cRM=.2a0fd783-08ee-475c-84a4-1a58a100c7f1@github.com>

On Tue, 21 Mar 2023 00:35:40 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 479:
> 
>> 477:      *     Otherwise, the invocation throws {@link WrongThreadException}; and</li>
>> 478:      *     <li>{@code A} is kept alive during the invocation. For instance, if {@code A} has been obtained using a
>> 479:      *     {@linkplain Arena#ofConfined() confined arena}, any attempt to {@linkplain Arena#close() close}
> 
> Is that correct? Do you mean a shared arena?

The text is correct (you can still close a confined arena from inside an upcall), but I agree that perhaps using a shared arena might be a bit more intuitive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143118512

From mcimadamore at openjdk.org  Tue Mar 21 09:56:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 09:56:53 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <lphoedvalFnqUzhydGb-ggq1yG1UpsZMZvaswVJTiYc=.4a1d0cac-a88b-4600-8531-643b7a2b25fb@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <lphoedvalFnqUzhydGb-ggq1yG1UpsZMZvaswVJTiYc=.4a1d0cac-a88b-4600-8531-643b7a2b25fb@github.com>
Message-ID: <JKtIE6vgQ3nHpk2pHQsYYkLNO0QtGNJY5c-rSgRrQLw=.a22c8183-fd95-4f07-bdcc-dddf706e733e@github.com>

On Tue, 21 Mar 2023 08:57:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
>> 
>>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>>> 620:          *
>>> 621:          * @see #captureCallState(String...)
>> 
>> How does a caller know what the structure may contain? Should we document the platform specific structures?
>
> I've added an example of how to print the platform-dependent structure. Should we document anyhow?

I'm not sure about this. Honestly, the example probably doesn't help much if somebody didn't get the idea of what the layout might be. I think it might be better to say something like, `on Windows/x64 the returned layout might be as follows...` and then you write the code to create the layout instance corresponding to the returned layout. But we have to be careful to make the text non-normative (as the set of values might change).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143125997

From mcimadamore at openjdk.org  Tue Mar 21 10:01:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 10:01:53 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
Message-ID: <YyfJ-JhtaJyXrw2pTqzppzYtwYlCF3CcTx-gQ-kceMw=.6af67667-35a5-41e7-ae27-9538c43bb443@github.com>

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Linker.java line 480:

> 478:      *     Otherwise, the invocation throws {@link WrongThreadException}; and</li>
> 479:      *     <li>{@code A} is kept alive during the invocation. For instance, if {@code A} has been obtained using a
> 480:      *     {@linkplain Arena#ofShared()} confined arena}, any attempt to {@linkplain Arena#close() close}

the description of the link still says "confined"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143131392

From pminborg at openjdk.org  Tue Mar 21 12:02:44 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 12:02:44 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <JKtIE6vgQ3nHpk2pHQsYYkLNO0QtGNJY5c-rSgRrQLw=.a22c8183-fd95-4f07-bdcc-dddf706e733e@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <lphoedvalFnqUzhydGb-ggq1yG1UpsZMZvaswVJTiYc=.4a1d0cac-a88b-4600-8531-643b7a2b25fb@github.com>
 <JKtIE6vgQ3nHpk2pHQsYYkLNO0QtGNJY5c-rSgRrQLw=.a22c8183-fd95-4f07-bdcc-dddf706e733e@github.com>
Message-ID: <fOJiFar9A4DhcguZVcFM61Zx4ZwX5BN4Zv8jHRxbn1M=.2b74ea12-4c90-4d37-acba-93a90de9f2ff@github.com>

On Tue, 21 Mar 2023 09:54:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've added an example of how to print the platform-dependent structure. Should we document anyhow?
>
> I'm not sure about this. Honestly, the example probably doesn't help much if somebody didn't get the idea of what the layout might be. I think it might be better to say something like, `on Windows/x64 the returned layout might be as follows...` and then you write the code to create the layout instance corresponding to the returned layout. But we have to be careful to make the text non-normative (as the set of values might change).

What about adding something like this?


Here is a list of valid names for some platforms:
    Linux:
        "errno"
    macOS:
        "errno"
    Windows:
        "GetLastError", "WSAGetLastError" and "errno"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143265595

From mcimadamore at openjdk.org  Tue Mar 21 12:08:45 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 12:08:45 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <fOJiFar9A4DhcguZVcFM61Zx4ZwX5BN4Zv8jHRxbn1M=.2b74ea12-4c90-4d37-acba-93a90de9f2ff@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <lphoedvalFnqUzhydGb-ggq1yG1UpsZMZvaswVJTiYc=.4a1d0cac-a88b-4600-8531-643b7a2b25fb@github.com>
 <JKtIE6vgQ3nHpk2pHQsYYkLNO0QtGNJY5c-rSgRrQLw=.a22c8183-fd95-4f07-bdcc-dddf706e733e@github.com>
 <fOJiFar9A4DhcguZVcFM61Zx4ZwX5BN4Zv8jHRxbn1M=.2b74ea12-4c90-4d37-acba-93a90de9f2ff@github.com>
Message-ID: <5VeF6VvOJ94JGz-slAqtwU-mtnhdV4qSk2KsbqVy-x4=.47d9a1f7-b86b-4d07-8ab1-f9abbaf3e5ed@github.com>

On Tue, 21 Mar 2023 11:58:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> I'm not sure about this. Honestly, the example probably doesn't help much if somebody didn't get the idea of what the layout might be. I think it might be better to say something like, `on Windows/x64 the returned layout might be as follows...` and then you write the code to create the layout instance corresponding to the returned layout. But we have to be careful to make the text non-normative (as the set of values might change).
>
> What about adding something like this?
> 
> 
> Here is a list of valid names for some platforms:
>     Linux:
>         "errno"
>     macOS:
>         "errno"
>     Windows:
>         "GetLastError", "WSAGetLastError" and "errno"

I'd prefer something more informal: "Examples of valid names are "errno" on Linux/x64, or "GetLastError" on Windows/x64". And maybe add that "The precise set of platform-dependent supported names can be queried using the returned group layout".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143272764

From mcimadamore at openjdk.org  Tue Mar 21 12:17:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 12:17:43 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
Message-ID: <pYRtChaFVMs_cb5b2yJOF5-sgqyjzFpO3k_fkNH8Ezo=.3acc93cd-65b4-4722-8761-7f4e725fe68c@github.com>

On Tue, 21 Mar 2023 00:54:10 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
> 
>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>> 620:          *
>> 621:          * @see #captureCallState(String...)
> 
> How does a caller know what the structure may contain? Should we document the platform specific structures?

Back to @PaulSandoz  question - "how does the caller know what the structure contains?". The caller typically doesn't care too much about what the returned struct is. But it might care about which "values" can be captured. That said, the set of such interesting values, is not too surprising. As demonstrated in the example in the `Linker.capturedCallState` method, once the client knows the name (and "errno" is likely to be 90% case), everything else follows from there - as the layout can be used to obtain var handles for the required values.

But, perhaps, now that I write this, I realize that what @PaulSandoz might _really_ be asking is: how do I know that e.g. the returned struct will not contain e.g. nested structs, sequences, or other non-sense. So we might specify (in a normative way) that the returned layout is a struct layout, whose member layouts are one or more value layouts (possibly with some added padding layouts). The names of the value layouts reflect the names of the values that can be captured.

And _then_ we show an example of the layout we return for Windows/x64 (as that's more interesting).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143281164

From pminborg at openjdk.org  Tue Mar 21 13:39:05 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 13:39:05 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
Message-ID: <hw0KAH255Qgpaf9TWe72S7DBFDPLju7BjAZo6Cnh7q0=.e4ce764d-37db-40c4-83bf-96705c0c80a1@github.com>

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

A review of all the copyright years shall be made in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1477849414

From bpb at openjdk.org  Tue Mar 21 16:52:58 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Mar 2023 16:52:58 GMT
Subject: RFR: 4842457: (bf spec) Clarify meaning of "(optional operation)"
Message-ID: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>

Add some clarifying verbiage about optional operations to the type-specific buffer classes.

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

Commit messages:
 - 4842457: (bf spec) Clarify meaning of "(optional operation)"

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

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

From alanb at openjdk.org  Tue Mar 21 18:28:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Mar 2023 18:28:44 GMT
Subject: RFR: 4842457: (bf spec) Clarify meaning of "(optional operation)"
In-Reply-To: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
References: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
Message-ID: <3PaX6kHzWJIHXgM_P0Hy-y36iYsdEMXImPnQ3kRwupc=.01cacfcb-9ac8-49e8-95c0-28b4f500ed60@github.com>

On Tue, 21 Mar 2023 16:43:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add some clarifying verbiage about optional operations to the type-specific buffer classes.

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

> 267:  * however, instead throw an {@linkplain UnsupportedOperationException} if the
> 268:  * $Type$Buffer is not backed by an {@linkplain Buffer#hasArray accessible
> 269:  * $type$ array} irrespective of whether the $Type$Buffer is read-only.

This mostly looks okay but I think it would be clearer to drop "however, instead"  and put "irrespective ..." in parentheses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13123#discussion_r1143835767

From alanb at openjdk.org  Tue Mar 21 18:29:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Mar 2023 18:29:42 GMT
Subject: RFR: 8304591: (fs) UnixPath.stringValue need not be volatile [v2]
In-Reply-To: <Anj1GDgwgRPHifuV2ilZYdaXD2xeai0GZ06MV-6ty70=.ec6ed3bc-e73f-4c33-8de5-2e2b4361e2b4@github.com>
References: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
 <Anj1GDgwgRPHifuV2ilZYdaXD2xeai0GZ06MV-6ty70=.ec6ed3bc-e73f-4c33-8de5-2e2b4361e2b4@github.com>
Message-ID: <C_xBDKiny02OJuOs-Zhu4TXQu8p7lx0c5ysxLJw2t7c=.fbd70b4a-b0da-4e0d-99cf-c5e7d1730758@github.com>

On Tue, 21 Mar 2023 09:27:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `UnixPath.stringValue` can be computed by multiple threads safely as the actual value is the same, so the race is benign in this case.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13115#pullrequestreview-1351157281

From bpb at openjdk.org  Tue Mar 21 19:19:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Mar 2023 19:19:43 GMT
Subject: RFR: 4842457: (bf spec) Clarify meaning of "(optional operation)"
In-Reply-To: <3PaX6kHzWJIHXgM_P0Hy-y36iYsdEMXImPnQ3kRwupc=.01cacfcb-9ac8-49e8-95c0-28b4f500ed60@github.com>
References: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
 <3PaX6kHzWJIHXgM_P0Hy-y36iYsdEMXImPnQ3kRwupc=.01cacfcb-9ac8-49e8-95c0-28b4f500ed60@github.com>
Message-ID: <7047fcqji3CNkvaAfl9dkZVI_7feLAmM7jkkBAzZa9A=.9a4316c7-4e23-48dc-8a42-89fabe80ecec@github.com>

On Tue, 21 Mar 2023 18:26:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add some clarifying verbiage about optional operations to the type-specific buffer classes.
>
> src/java.base/share/classes/java/nio/X-Buffer.java.template line 269:
> 
>> 267:  * however, instead throw an {@linkplain UnsupportedOperationException} if the
>> 268:  * $Type$Buffer is not backed by an {@linkplain Buffer#hasArray accessible
>> 269:  * $type$ array} irrespective of whether the $Type$Buffer is read-only.
> 
> This mostly looks okay but I think it would be clearer to drop "however, instead"  and put "irrespective ..." in parentheses.

I thought "however, instead" a bit clunky as well; will update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13123#discussion_r1143886924

From bpb at openjdk.org  Tue Mar 21 19:22:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Mar 2023 19:22:41 GMT
Subject: RFR: 8304591: (fs) UnixPath.stringValue need not be volatile [v2]
In-Reply-To: <Anj1GDgwgRPHifuV2ilZYdaXD2xeai0GZ06MV-6ty70=.ec6ed3bc-e73f-4c33-8de5-2e2b4361e2b4@github.com>
References: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
 <Anj1GDgwgRPHifuV2ilZYdaXD2xeai0GZ06MV-6ty70=.ec6ed3bc-e73f-4c33-8de5-2e2b4361e2b4@github.com>
Message-ID: <jFdK5Pf9gOOBeaajfro18ChRzT0s2VAGdQyouXAgTgQ=.babc1eee-a52c-41d8-87a5-2a31141a2402@github.com>

On Tue, 21 Mar 2023 09:27:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `UnixPath.stringValue` can be computed by multiple threads safely as the actual value is the same, so the race is benign in this case.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13115#pullrequestreview-1351236400

From bpb at openjdk.org  Tue Mar 21 19:30:30 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Mar 2023 19:30:30 GMT
Subject: RFR: 4842457: (bf spec) Clarify meaning of "(optional operation)"
 [v2]
In-Reply-To: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
References: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
Message-ID: <Ore6yw5G9_Fa5oKQLu-94oL5mKofj2gpopSPHIChybU=.89983a33-848f-40d8-aeae-1fa82bbb5e4d@github.com>

> Add some clarifying verbiage about optional operations to the type-specific buffer classes.

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

  4842457: Refine verbiage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13123/files
  - new: https://git.openjdk.org/jdk/pull/13123/files/3d18bd29..12e5fe15

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

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

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

From bpb at openjdk.org  Tue Mar 21 19:30:33 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Mar 2023 19:30:33 GMT
Subject: RFR: 4842457: (bf spec) Clarify meaning of "(optional operation)"
 [v2]
In-Reply-To: <7047fcqji3CNkvaAfl9dkZVI_7feLAmM7jkkBAzZa9A=.9a4316c7-4e23-48dc-8a42-89fabe80ecec@github.com>
References: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
 <3PaX6kHzWJIHXgM_P0Hy-y36iYsdEMXImPnQ3kRwupc=.01cacfcb-9ac8-49e8-95c0-28b4f500ed60@github.com>
 <7047fcqji3CNkvaAfl9dkZVI_7feLAmM7jkkBAzZa9A=.9a4316c7-4e23-48dc-8a42-89fabe80ecec@github.com>
Message-ID: <gl5KBjb2nhrz1DRmVx6LwMAm8H-hfFkzqwrwtgszavg=.8f5de717-d971-484d-ba01-7ad34cc30a7f@github.com>

On Tue, 21 Mar 2023 19:16:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/X-Buffer.java.template line 269:
>> 
>>> 267:  * however, instead throw an {@linkplain UnsupportedOperationException} if the
>>> 268:  * $Type$Buffer is not backed by an {@linkplain Buffer#hasArray accessible
>>> 269:  * $type$ array} irrespective of whether the $Type$Buffer is read-only.
>> 
>> This mostly looks okay but I think it would be clearer to drop "however, instead"  and put "irrespective ..." in parentheses.
>
> I thought "however, instead" a bit clunky as well; will update.

Refined in 12e5fe15237a5f5cebbaf2ed4e81a851074e3e5c.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13123#discussion_r1143895168

From bpb at openjdk.org  Tue Mar 21 19:34:28 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Mar 2023 19:34:28 GMT
Subject: RFR: 4842457: (bf spec) Clarify meaning of "(optional operation)"
 [v3]
In-Reply-To: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
References: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
Message-ID: <TkLVlURMYMwO_mLQOdjmaoCUA5ygYZB12mHGPYEgF3o=.dda861f6-4ee1-4e04-b0d1-a2247ed224cd@github.com>

> Add some clarifying verbiage about optional operations to the type-specific buffer classes.

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

  4842457: Remove vestigial comma; clean up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13123/files
  - new: https://git.openjdk.org/jdk/pull/13123/files/12e5fe15..93febb09

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

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

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

From alanb at openjdk.org  Tue Mar 21 20:17:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Mar 2023 20:17:41 GMT
Subject: RFR: 4842457: (bf spec) Clarify meaning of "(optional operation)"
 [v3]
In-Reply-To: <TkLVlURMYMwO_mLQOdjmaoCUA5ygYZB12mHGPYEgF3o=.dda861f6-4ee1-4e04-b0d1-a2247ed224cd@github.com>
References: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
 <TkLVlURMYMwO_mLQOdjmaoCUA5ygYZB12mHGPYEgF3o=.dda861f6-4ee1-4e04-b0d1-a2247ed224cd@github.com>
Message-ID: <B2dQmZmwcQ1LRluYcxjyW2eEDhThtTFFW8UxJpyM0v0=.73799973-4882-4486-9ce4-9a225b54cb05@github.com>

On Tue, 21 Mar 2023 19:34:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some clarifying verbiage about optional operations to the type-specific buffer classes.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4842457: Remove vestigial comma; clean up

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13123#pullrequestreview-1351315477

From duke at openjdk.org  Tue Mar 21 21:48:02 2023
From: duke at openjdk.org (Markus KARG)
Date: Tue, 21 Mar 2023 21:48:02 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v21]
In-Reply-To: <4J5-MPn4DiG3ZB4rDGy9725Qb7VrqQJIjb-mW7cI520=.c75c7030-834c-4ed4-93b0-03bb18231785@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <cZUqlMDfHxytpHyVR56ywnxZA_7pEdogM_k2XJz1swM=.2709b5ba-60d9-455e-a2d6-dd28c97606e2@github.com>
 <4J5-MPn4DiG3ZB4rDGy9725Qb7VrqQJIjb-mW7cI520=.c75c7030-834c-4ed4-93b0-03bb18231785@github.com>
Message-ID: <NRlswTtfjwEZshzBc0FjN1hPRN4ao285HSYMFJ62jUk=.378a476e-bcf8-4b4e-bd5a-5ace89c8df44@github.com>

On Mon, 20 Mar 2023 21:00:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Abstracted testMoreThanTwoGB
>
> test/jdk/java/nio/channels/Channels/TransferToBase.java line 222:
> 
>> 220:                         byte[] rndBytes = createRandomBytes(BYTES_PER_WRITE, 0);
>> 221:                         ByteBuffer src = ByteBuffer.wrap(rndBytes);
>> 222:                         fc.write(src);
> 
> Should this code perhaps allow for a short write, i.e., `FileChannel::write` returning a value less than `rndBytes.length`? For example, something like this:
> 
>                     long pos = initPos;
>                     while (pos < BYTES_WRITTEN) {
>                         int len = Math.toIntExact(BYTES_WRITTEN - pos);
>                         if (len > BYTES_PER_WRITE)
>                             len = BYTES_PER_WRITE;
>                         byte[] rndBytes = createRandomBytes(len, 0);
>                         ByteBuffer src = ByteBuffer.wrap(rndBytes);
>                         pos += fc.write(src);
>                     }

I have incorporated your proposed code change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/6711#discussion_r1144017216

From duke at openjdk.org  Tue Mar 21 21:47:59 2023
From: duke at openjdk.org (Markus KARG)
Date: Tue, 21 Mar 2023 21:47:59 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v22]
In-Reply-To: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
Message-ID: <L7cbFqrlbFEhkPLzFwztKd-07PcbbyrFbdvuLQnFkNk=.6b6d670a-2665-478d-bdef-3b9008cb2432@github.com>

> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.

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

  Dealing with FileChannel::write returning a value less than rndBytes.length

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/6711/files
  - new: https://git.openjdk.org/jdk/pull/6711/files/fb198503..8b7425ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=6711&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=6711&range=20-21

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

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

From bpb at openjdk.org  Tue Mar 21 23:38:28 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Mar 2023 23:38:28 GMT
Subject: RFR: 8202110: (fs) Default file system provider should load
 UnixNativeDispatcher lazily
Message-ID: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>

Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.

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

Commit messages:
 - 8202110: (fs) Default file system provider should load UnixNativeDispatcher lazily

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

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

From fjiang at openjdk.org  Wed Mar 22 08:18:42 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Wed, 22 Mar 2023 08:18:42 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <hw0KAH255Qgpaf9TWe72S7DBFDPLju7BjAZo6Cnh7q0=.e4ce764d-37db-40c4-83bf-96705c0c80a1@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
 <hw0KAH255Qgpaf9TWe72S7DBFDPLju7BjAZo6Cnh7q0=.e4ce764d-37db-40c4-83bf-96705c0c80a1@github.com>
Message-ID: <2VN0jPv3cwJuzneVkIBwHReDI-2zj0qBknbc_AeFy1k=.d306ef5f-c104-496b-b6fd-f404ffc33d39@github.com>

On Tue, 21 Mar 2023 13:35:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> A review of all the copyright years shall be made in this PR.

Hi @minborg, looks like some changes were missed on riscv port. I've added these changes and submitted tests on linux-riscv. `jdk_foreign` still passed with release & fatdebug build.
Could you please add these extra changes for riscv? Thanks.
 Here is the patch: [foreign_riscv_port_patch.txt](https://github.com/openjdk/jdk/files/11037700/foreign_riscv_port_patch.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1479083052

From aturbanov at openjdk.org  Wed Mar 22 09:18:50 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 22 Mar 2023 09:18:50 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
Message-ID: <gzhf1XGVQ5tRQEVfr8tYaMuzjiPKtwShUwfNsxnovQQ=.4863cbee-19c8-4eb3-8c36-a8cd069c23cd@github.com>

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Arena.java line 224:

> 222:     static Arena global() {
> 223:         class Holder {
> 224:             final static Arena GLOBAL = MemorySessionImpl.GLOBAL.asArena();

Nit: use blessed modifiers order
Suggestion:

            static final Arena GLOBAL = MemorySessionImpl.GLOBAL.asArena();

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/windows/WindowsAArch64Linker.java line 58:

> 56:     @Override
> 57:     protected UpcallStubFactory arrangeUpcall(MethodType targetType, FunctionDescriptor function, LinkerOptions options) {
> 58:         return  CallArranger.WINDOWS.arrangeUpcall(targetType, function, options);

Suggestion:

        return CallArranger.WINDOWS.arrangeUpcall(targetType, function, options);

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 159:

> 157:      */
> 158:     static void getStructOffsets(MemorySegment structType, MemorySegment offsetsOut, FFIABI abi)
> 159:             throws IllegalStateException  {

Suggestion:

            throws IllegalStateException {

test/jdk/java/foreign/trivial/TestTrivial.java line 74:

> 72:         VarHandle vhX = bigLayout.varHandle(MemoryLayout.PathElement.groupElement("x"));
> 73:         VarHandle vhY = bigLayout.varHandle(MemoryLayout.PathElement.groupElement("y"));
> 74:         try (Arena arena  = Arena.ofConfined()) {

nit:
Suggestion:

        try (Arena arena = Arena.ofConfined()) {

test/jdk/java/foreign/trivial/TestTrivial.java line 89:

> 87:         StructLayout capturedStateLayout = Linker.Option.captureStateLayout();
> 88:         VarHandle errnoHandle = capturedStateLayout.varHandle(MemoryLayout.PathElement.groupElement("errno"));
> 89:         try (Arena arena  = Arena.ofConfined()) {

nit
Suggestion:

        try (Arena arena = Arena.ofConfined()) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144450371
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144453152
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144452221
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144451413
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144451634

From mcimadamore at openjdk.org  Wed Mar 22 11:57:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 11:57:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
Message-ID: <SJH6UHgJox37XpsedV_d9PZvTUfrycOKt_diWtoYO5c=.d7a45b10-42d3-492f-aff5-b5886245ff13@github.com>

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 694:

> 692:      * @param bitSize the padding size in bits.
> 693:      * @return the new selector layout.
> 694:      * @throws IllegalArgumentException if {@code bitSize < 0} or {@code bitSize % 8 != 0}

I'm not sure if this change in the `@throws` was deliberate - e.g. the new API seems to allow creation of padding layouts of zero size (which I did not realize). This can hide issues for code generators (e.g. I stumbled upon this when working on jextract, which was silently emitting zero-length paddings in some struct layouts). Perhaps better to revert to old semantics?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144680066

From pminborg at openjdk.org  Wed Mar 22 12:10:46 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 12:10:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <SJH6UHgJox37XpsedV_d9PZvTUfrycOKt_diWtoYO5c=.d7a45b10-42d3-492f-aff5-b5886245ff13@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
 <SJH6UHgJox37XpsedV_d9PZvTUfrycOKt_diWtoYO5c=.d7a45b10-42d3-492f-aff5-b5886245ff13@github.com>
Message-ID: <aS49h7SJaduLKRjSabqCs4yQxKGuYDOcfejU2s0cHkQ=.189a240a-f460-42f3-8334-7873296929fd@github.com>

On Wed, 22 Mar 2023 11:55:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 694:
> 
>> 692:      * @param bitSize the padding size in bits.
>> 693:      * @return the new selector layout.
>> 694:      * @throws IllegalArgumentException if {@code bitSize < 0} or {@code bitSize % 8 != 0}
> 
> I'm not sure if this change in the `@throws` was deliberate - e.g. the new API seems to allow creation of padding layouts of zero size (which I did not realize). This can hide issues for code generators (e.g. I stumbled upon this when working on jextract, which was silently emitting zero-length paddings in some struct layouts). Perhaps better to revert to old semantics?

Agreed. Having zero-length padding does not make much sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144707890

From pminborg at openjdk.org  Wed Mar 22 12:28:14 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 12:28:14 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v6]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <MHpaK7KKdxcC8zsUlJZTznmqHfwSDeYB9pNYi9TxNy4=.6c70426b-fd02-408b-8d65-7e7ec82a6ec2@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

 - Fix formating and modifier order
 - Fix typo -> shared arena

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/21ef0607..192050d6

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

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

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

From pminborg at openjdk.org  Wed Mar 22 13:58:35 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 13:58:35 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v7]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <uTRqJUGYsaK9AMwCr7AxGMYjG3wXpoeC5QWiuyl3Jnc=.ec51f592-d340-4177-9a33-2d7df2da5f99@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

  Disalow padding layouts of size zero

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/192050d6..45febe9d

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

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

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

From pminborg at openjdk.org  Wed Mar 22 14:09:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 14:09:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

  Improve javadocs for Linker::captureStateLayout

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/45febe9d..6df28a78

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

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

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

From pminborg at openjdk.org  Wed Mar 22 14:09:56 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 14:09:56 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <pYRtChaFVMs_cb5b2yJOF5-sgqyjzFpO3k_fkNH8Ezo=.3acc93cd-65b4-4722-8761-7f4e725fe68c@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <pYRtChaFVMs_cb5b2yJOF5-sgqyjzFpO3k_fkNH8Ezo=.3acc93cd-65b4-4722-8761-7f4e725fe68c@github.com>
Message-ID: <jPVaoTe4yDNcopVbNL3HV2reRvc7C_wLR1uRdhfkgNM=.bd715322-36b4-4bfb-bee7-b25fa61fc73e@github.com>

On Tue, 21 Mar 2023 12:12:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
>> 
>>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>>> 620:          *
>>> 621:          * @see #captureCallState(String...)
>> 
>> How does a caller know what the structure may contain? Should we document the platform specific structures?
>
> Back to @PaulSandoz  question - "how does the caller know what the structure contains?". The caller typically doesn't care too much about what the returned struct is. But it might care about which "values" can be captured. That said, the set of such interesting values, is not too surprising. As demonstrated in the example in the `Linker.capturedCallState` method, once the client knows the name (and "errno" is likely to be 90% case), everything else follows from there - as the layout can be used to obtain var handles for the required values.
> 
> But, perhaps, now that I write this, I realize that what @PaulSandoz might _really_ be asking is: how do I know that e.g. the returned struct will not contain e.g. nested structs, sequences, or other non-sense. So we might specify (in a normative way) that the returned layout is a struct layout, whose member layouts are one or more value layouts (possibly with some added padding layouts). The names of the value layouts reflect the names of the values that can be captured.
> 
> And _then_ we show an example of the layout we return for Windows/x64 (as that's more interesting).

I've updated the specs as per how I interpret the comments above. Let me know your thoughts on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144872865

From alanb at openjdk.org  Wed Mar 22 14:14:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Mar 2023 14:14:49 GMT
Subject: RFR: 8202110: (fs) Default file system provider should load
 UnixNativeDispatcher lazily
In-Reply-To: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
Message-ID: <X2i8PXrg6VOE6zUH7GjX95fgbUX3In-PoIULYp8u6AI=.498cab76-fcfb-4bd9-8015-7029b7688468@github.com>

On Tue, 21 Mar 2023 23:31:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 123:

> 121:                 this.needToResolveAgainstDefaultDirectory = !defaultIsCwd;
> 122:             }
> 123:         }

Making needToResolveAgainstDefaultDirectory a tri-state is a bit ugly. If we really need to defer this then it might be better to just move the field to Holder class, that way this method would return holder.needToResolveAgainstDefaultDirectory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13132#discussion_r1144879997

From mcimadamore at openjdk.org  Wed Mar 22 14:38:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 14:38:30 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
Message-ID: <Iu1RS7_q9ZObK7zlXpfAlipAD1qeMyGBxa_QQS5Qx8E=.e24807ba-abb5-4189-9870-6d3830c6d7a6@github.com>

On Wed, 22 Mar 2023 14:09:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadocs for Linker::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Linker.java line 628:

> 626:          * and possibly {@linkplain PaddingLayout padding layouts}.
> 627:          * As an example, on Windows, the returned layout might contain three value layouts named:
> 628:          * <ul>

Almost there - instead of listing the names, just put a code snippet with the struct layout! That will make it crystal clear.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 697:

> 695:      */
> 696:     static PaddingLayout paddingLayout(long bitSize) {
> 697:         if (bitSize <= 0) {

While this does the right thing, I wonder if we can do better, as it seems we're checking size twice - perhaps we need to customize the `requireBitSizeValid` function?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144915578
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144917200

From pminborg at openjdk.org  Wed Mar 22 16:18:47 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 16:18:47 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <Iu1RS7_q9ZObK7zlXpfAlipAD1qeMyGBxa_QQS5Qx8E=.e24807ba-abb5-4189-9870-6d3830c6d7a6@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <Iu1RS7_q9ZObK7zlXpfAlipAD1qeMyGBxa_QQS5Qx8E=.e24807ba-abb5-4189-9870-6d3830c6d7a6@github.com>
Message-ID: <L3Iof3hrKFzHZV7zw8jTKT-tzCkaV2sBMZE8tszHC30=.be7d7dbd-1aa0-4b7e-a224-e07db7f21d16@github.com>

On Wed, 22 Mar 2023 14:35:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 697:
> 
>> 695:      */
>> 696:     static PaddingLayout paddingLayout(long bitSize) {
>> 697:         if (bitSize <= 0) {
> 
> While this does the right thing, I wonder if we can do better, as it seems we're checking size twice - perhaps we need to customize the `requireBitSizeValid` function?

I tried that but it turned out it can be zero in other contexts. Maybe we should add back the good 'ole "allowZero" flag?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145052056

From mcimadamore at openjdk.org  Wed Mar 22 16:53:45 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 16:53:45 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <L3Iof3hrKFzHZV7zw8jTKT-tzCkaV2sBMZE8tszHC30=.be7d7dbd-1aa0-4b7e-a224-e07db7f21d16@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <Iu1RS7_q9ZObK7zlXpfAlipAD1qeMyGBxa_QQS5Qx8E=.e24807ba-abb5-4189-9870-6d3830c6d7a6@github.com>
 <L3Iof3hrKFzHZV7zw8jTKT-tzCkaV2sBMZE8tszHC30=.be7d7dbd-1aa0-4b7e-a224-e07db7f21d16@github.com>
Message-ID: <7ShkwGh4K35ZoSJ13mwrlp-VDg0NCIDeiNGoV8lYwJE=.39fe2eaf-d253-4853-9438-bd9de7a1864b@github.com>

On Wed, 22 Mar 2023 15:57:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 697:
>> 
>>> 695:      */
>>> 696:     static PaddingLayout paddingLayout(long bitSize) {
>>> 697:         if (bitSize <= 0) {
>> 
>> While this does the right thing, I wonder if we can do better, as it seems we're checking size twice - perhaps we need to customize the `requireBitSizeValid` function?
>
> I tried that but it turned out it can be zero in other contexts. Maybe we should add back the good 'ole "allowZero" flag?

yeah , a boolean seems good enough

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145136161

From jvernee at openjdk.org  Wed Mar 22 18:47:59 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Mar 2023 18:47:59 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
Message-ID: <gtAJNliiAynBqS9eqqm_KHudLRsvufMr_7FjxOliObI=.a95210da-075c-47a9-a38a-dadb793e3362@github.com>

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Arena.java line 59:

> 57:  * which features a <em>bounded lifetime</em> that is managed, automatically, by the garbage collector. As such, the regions
> 58:  * of memory backing memory segments allocated with the automatic arena are deallocated at some unspecified time
> 59:  * <em>after</em> the automatic allocator (and all the segments allocated by it) become

Suggestion:

 * <em>after</em> the automatic arena (and all the segments allocated by it) become

src/java.base/share/classes/java/lang/foreign/Arena.java line 89:

> 87:  * Memory segments allocated with a {@linkplain #ofConfined() confined arena} can only be accessed (and closed) by the
> 88:  * thread that created the arena. If access to a memory segment from multiple threads is required, clients can allocate
> 89:  * segment in a {@linkplain #ofShared() shared arena} instead.

Suggestion:

 * segments in a {@linkplain #ofShared() shared arena} instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143734059
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143738342

From jvernee at openjdk.org  Wed Mar 22 18:48:07 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Mar 2023 18:48:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
Message-ID: <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>

On Wed, 22 Mar 2023 14:09:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadocs for Linker::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Linker.java line 492:

> 490:      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
> 491:      * parameter passed to it is associated with the {@link MemorySegment#NULL} address, or a {@link NullPointerException}
> 492:      * if that parameter is {@code null}.

I think this isn't quite correct, as it only applies to the target address parameter. Also, we don't have to mention the NPE, as that's already mentioned in the package doc
Suggestion:

     * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
     * representing the target address of the foreign function is the {@link MemorySegment#NULL} address.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2315:

> 2313:          * @return {@code true}, if the provided object is also a scope, which models the same lifetime as that
> 2314:          * modelled by this scope.
> 2315:          */

A `@return` tag could be used here
Suggestion:

        /**
         * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
         * modelled by this scope.} In that case, it is always the case that
         * {@code this.isAlive() == ((Scope)that).isAlive()}.
         * @param that the object to be tested.
         */

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FFIType.java line 116:

> 114:             }
> 115:             assert grpl instanceof UnionLayout;
> 116:             throw new IllegalArgumentException("Fallback linker does not support by-value unions: " + grpl);

For posterity, I suggest adding a comment here with the the bug number.
Suggestion:

            // JDK-8301800
            throw new IllegalArgumentException("Fallback linker does not support by-value unions: " + grpl);

src/java.base/share/native/libfallbackLinker/fallbackLinker.c line 82:

> 80:     value_ptr++;
> 81:   }
> 82: #endif

This looks incorrect. Look at the changes to `downcallLinker.cpp`, the `value_ptr++` should be moved outside of the if statements. (it only matters on Windows though, which we can't test at the moment for the fallback linker, but let's keep the 2 impls in sync for now)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145188849
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145221286
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145245662
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145258121

From mcimadamore at openjdk.org  Wed Mar 22 19:05:49 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 19:05:49 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
Message-ID: <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>

On Wed, 22 Mar 2023 17:34:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 492:
> 
>> 490:      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>> 491:      * parameter passed to it is associated with the {@link MemorySegment#NULL} address, or a {@link NullPointerException}
>> 492:      * if that parameter is {@code null}.
> 
> I think this isn't quite correct, as it only applies to the target address parameter. Also, we don't have to mention the NPE, as that's already mentioned in the package doc
> Suggestion:
> 
>      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>      * representing the target address of the foreign function is the {@link MemorySegment#NULL} address.

Note: this text was just copied/adapted from toplevel javadoc and moved here. I think we have to say something about `null` as the text refers to `null` being passed as parameter to the returned MH, which is NOT covered by the package javadoc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145281749

From mcimadamore at openjdk.org  Wed Mar 22 19:09:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 19:09:27 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
Message-ID: <Tj3Ufw1gbQtPg_3o3SZ0AA_8cyAEMaAomuDJvKPZgaM=.1c629dec-fce5-485c-aa27-cad5b4c41d44@github.com>

On Wed, 22 Mar 2023 18:04:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2315:
> 
>> 2313:          * @return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>> 2314:          * modelled by this scope.
>> 2315:          */
> 
> A `@return` tag could be used here
> Suggestion:
> 
>         /**
>          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>          * modelled by this scope.} In that case, it is always the case that
>          * {@code this.isAlive() == ((Scope)that).isAlive()}.
>          * @param that the object to be tested.
>          */

Oh - I didn't know you could use return tag plus other text...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145284853

From jvernee at openjdk.org  Wed Mar 22 19:27:47 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Mar 2023 19:27:47 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
Message-ID: <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>

On Wed, 22 Mar 2023 19:02:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 492:
>> 
>>> 490:      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>>> 491:      * parameter passed to it is associated with the {@link MemorySegment#NULL} address, or a {@link NullPointerException}
>>> 492:      * if that parameter is {@code null}.
>> 
>> I think this isn't quite correct, as it only applies to the target address parameter. Also, we don't have to mention the NPE, as that's already mentioned in the package doc
>> Suggestion:
>> 
>>      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>>      * representing the target address of the foreign function is the {@link MemorySegment#NULL} address.
>
> Note: this text was just copied/adapted from toplevel javadoc and moved here. I think we have to say something about `null` as the text refers to `null` being passed as parameter to the returned MH, which is NOT covered by the package javadoc.

Ah. True. This is true about all the MS parameters as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145303573

From mcimadamore at openjdk.org  Wed Mar 22 20:09:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 20:09:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>
Message-ID: <yWgrZFrwKiPd5c9G1JUMJfv3xjtl8fYJ-GFr5sPsdwk=.d660f1f6-0d7c-42ce-8fca-9c3309c2a160@github.com>

On Wed, 22 Mar 2023 19:25:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Note: this text was just copied/adapted from toplevel javadoc and moved here. I think we have to say something about `null` as the text refers to `null` being passed as parameter to the returned MH, which is NOT covered by the package javadoc.
>
> Ah. True. This is true about all the MS parameters as well.

Yes - although there is a distinction between passed by value and by ref. I wouldn't be surprised if we just threw NPE for by-value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145352294

From bpb at openjdk.org  Wed Mar 22 22:44:19 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Mar 2023 22:44:19 GMT
Subject: RFR: 4842457: (bf spec) Clarify meaning of "(optional operation)"
 [v4]
In-Reply-To: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
References: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
Message-ID: <c5F_mB07S5hxQdK1CDf6s31u9cBXh3LbuePJSYm1MC8=.9e5b26fa-d0ed-404c-aedb-0a512e926e51@github.com>

> Add some clarifying verbiage about optional operations to the type-specific buffer classes.

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

  4842457: Use javadoc ## support in @linkplain

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13123/files
  - new: https://git.openjdk.org/jdk/pull/13123/files/93febb09..4dbbf0fe

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

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

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

From alanb at openjdk.org  Thu Mar 23 06:57:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Mar 2023 06:57:43 GMT
Subject: RFR: 4842457: (bf spec) Clarify meaning of "(optional operation)"
 [v4]
In-Reply-To: <c5F_mB07S5hxQdK1CDf6s31u9cBXh3LbuePJSYm1MC8=.9e5b26fa-d0ed-404c-aedb-0a512e926e51@github.com>
References: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
 <c5F_mB07S5hxQdK1CDf6s31u9cBXh3LbuePJSYm1MC8=.9e5b26fa-d0ed-404c-aedb-0a512e926e51@github.com>
Message-ID: <3NiV-vIn_OSMJMeIS0ULiUl63bBIVrOBNLlTm6OHQFc=.3ca43361-073e-491c-abf2-8163cd09b609@github.com>

On Wed, 22 Mar 2023 22:44:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some clarifying verbiage about optional operations to the type-specific buffer classes.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4842457: Use javadoc ## support in @linkplain

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13123#pullrequestreview-1353952828

From mcimadamore at openjdk.org  Thu Mar 23 10:30:47 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 23 Mar 2023 10:30:47 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <yWgrZFrwKiPd5c9G1JUMJfv3xjtl8fYJ-GFr5sPsdwk=.d660f1f6-0d7c-42ce-8fca-9c3309c2a160@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>
 <yWgrZFrwKiPd5c9G1JUMJfv3xjtl8fYJ-GFr5sPsdwk=.d660f1f6-0d7c-42ce-8fca-9c3309c2a160@github.com>
Message-ID: <Dnp-mfHydFBZL0PJJxMhG9nYnB4P9MFthqvSmv8IdLY=.4154cc1f-66ea-46c7-a6d3-a4add7e94844@github.com>

On Wed, 22 Mar 2023 20:07:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Ah. True. This is true about all the MS parameters as well.
>
> Yes - although there is a distinction between passed by value and by ref. I wouldn't be surprised if we just threw NPE for by-value.

Just did a test with jshell:


jshell> Linker linker = Linker.nativeLinker();

jshell> MethodHandle handleValue = linker.downcallHandle(FunctionDescriptor.ofVoid(MemoryLayout.structLayout(ValueLayout.JAVA_INT)));
handleValue ==> MethodHandle(MemorySegment,MemorySegment)void

jshell> handleValue.invoke(MemorySegment.ofAddress(1), null);
|  Exception java.lang.NullPointerException
|        at (#5:1)


So, yes, passing `null` for a "by-value" struct issues NPEs. I also get same exception when calling a method handle which passes a struct by reference:


jshell> MethodHandle handleRef = linker.downcallHandle(FunctionDescriptor.ofVoid(ValueLayout.ADDRESS));
handleRef ==> MethodHandle(MemorySegment,MemorySegment)void

jshell> handleRef.invoke(MemorySegment.ofAddress(1), null);
|  Exception java.lang.NullPointerException
|        at (#7:1)


Given what the impl does, to be fair I don't mind the NPE (it seems a good exception to throw if we're passing a raw `null`). But we should document it at such.

It also seems like the first parameter of the downcall has somewhat better checks (but still NPEs):


jshell> handleRef.invoke(null, MemorySegment.ofAddress(1));
|  Exception java.lang.NullPointerException
|        at Objects.requireNonNull (Objects.java:233)
|        at SharedUtils.checkSymbol (SharedUtils.java:351)
|        at (#8:1)


And:


jshell> handleRef.invoke(MemorySegment.NULL, MemorySegment.ofAddress(1));
|  Exception java.lang.IllegalArgumentException: Symbol is NULL: MemorySegment{ heapBase: Optional.empty address:0 limit: 0 }
|        at SharedUtils.checkSymbol (SharedUtils.java:353)
|        at (#9:1)


I think this last case is the _only_ one where IAE is warranted - as the role of the first parameter is special, and we can't tolerate a `MemorySegment::NULL` there. For all other reference parameters, the downcall handle should just check that they are non-null, and throw if so.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145978702

From mcimadamore at openjdk.org  Thu Mar 23 10:34:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 23 Mar 2023 10:34:50 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <Dnp-mfHydFBZL0PJJxMhG9nYnB4P9MFthqvSmv8IdLY=.4154cc1f-66ea-46c7-a6d3-a4add7e94844@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>
 <yWgrZFrwKiPd5c9G1JUMJfv3xjtl8fYJ-GFr5sPsdwk=.d660f1f6-0d7c-42ce-8fca-9c3309c2a160@github.com>
 <Dnp-mfHydFBZL0PJJxMhG9nYnB4P9MFthqvSmv8IdLY=.4154cc1f-66ea-46c7-a6d3-a4add7e94844@github.com>
Message-ID: <QzxKSr0yyGvC-V_dXbvxeywSxyy9sWgsl1mFeukWzIY=.35ba1839-8859-49bf-879c-638f9af58758@github.com>

On Thu, 23 Mar 2023 10:28:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yes - although there is a distinction between passed by value and by ref. I wouldn't be surprised if we just threw NPE for by-value.
>
> Just did a test with jshell:
> 
> 
> jshell> Linker linker = Linker.nativeLinker();
> 
> jshell> MethodHandle handleValue = linker.downcallHandle(FunctionDescriptor.ofVoid(MemoryLayout.structLayout(ValueLayout.JAVA_INT)));
> handleValue ==> MethodHandle(MemorySegment,MemorySegment)void
> 
> jshell> handleValue.invoke(MemorySegment.ofAddress(1), null);
> |  Exception java.lang.NullPointerException
> |        at (#5:1)
> 
> 
> So, yes, passing `null` for a "by-value" struct issues NPEs. I also get same exception when calling a method handle which passes a struct by reference:
> 
> 
> jshell> MethodHandle handleRef = linker.downcallHandle(FunctionDescriptor.ofVoid(ValueLayout.ADDRESS));
> handleRef ==> MethodHandle(MemorySegment,MemorySegment)void
> 
> jshell> handleRef.invoke(MemorySegment.ofAddress(1), null);
> |  Exception java.lang.NullPointerException
> |        at (#7:1)
> 
> 
> Given what the impl does, to be fair I don't mind the NPE (it seems a good exception to throw if we're passing a raw `null`). But we should document it at such.
> 
> It also seems like the first parameter of the downcall has somewhat better checks (but still NPEs):
> 
> 
> jshell> handleRef.invoke(null, MemorySegment.ofAddress(1));
> |  Exception java.lang.NullPointerException
> |        at Objects.requireNonNull (Objects.java:233)
> |        at SharedUtils.checkSymbol (SharedUtils.java:351)
> |        at (#8:1)
> 
> 
> And:
> 
> 
> jshell> handleRef.invoke(MemorySegment.NULL, MemorySegment.ofAddress(1));
> |  Exception java.lang.IllegalArgumentException: Symbol is NULL: MemorySegment{ heapBase: Optional.empty address:0 limit: 0 }
> |        at SharedUtils.checkSymbol (SharedUtils.java:353)
> |        at (#9:1)
> 
> 
> I think this last case is the _only_ one where IAE is warranted - as the role of the first parameter is special, and we can't tolerate a `MemorySegment::NULL` there. For all other reference parameters, the downcall handle should just check that they are non-null, and throw if so.

The returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
representing the target address of the foreign function is the {@link MemorySegment#NULL} address.
The returned method handle will additionally throw {@link NullPointerException} if any parameter of type {@link MemorySegment} is {@code null}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145982159

From jvernee at openjdk.org  Thu Mar 23 14:16:03 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 23 Mar 2023 14:16:03 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <QzxKSr0yyGvC-V_dXbvxeywSxyy9sWgsl1mFeukWzIY=.35ba1839-8859-49bf-879c-638f9af58758@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>
 <yWgrZFrwKiPd5c9G1JUMJfv3xjtl8fYJ-GFr5sPsdwk=.d660f1f6-0d7c-42ce-8fca-9c3309c2a160@github.com>
 <Dnp-mfHydFBZL0PJJxMhG9nYnB4P9MFthqvSmv8IdLY=.4154cc1f-66ea-46c7-a6d3-a4add7e94844@github.com>
 <QzxKSr0yyGvC-V_dXbvxeywSxyy9sWgsl1mFeukWzIY=.35ba1839-8859-49bf-879c-638f9af58758@github.com>
Message-ID: <fyVsvw-Pdq0GxPkP2AdaNkXUtzz0A2MiibYLeCV3pyQ=.d6142df1-4338-4d45-a206-ae4966d293a0@github.com>

On Thu, 23 Mar 2023 10:31:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Just did a test with jshell:
>> 
>> 
>> jshell> Linker linker = Linker.nativeLinker();
>> 
>> jshell> MethodHandle handleValue = linker.downcallHandle(FunctionDescriptor.ofVoid(MemoryLayout.structLayout(ValueLayout.JAVA_INT)));
>> handleValue ==> MethodHandle(MemorySegment,MemorySegment)void
>> 
>> jshell> handleValue.invoke(MemorySegment.ofAddress(1), null);
>> |  Exception java.lang.NullPointerException
>> |        at (#5:1)
>> 
>> 
>> So, yes, passing `null` for a "by-value" struct issues NPEs. I also get same exception when calling a method handle which passes a struct by reference:
>> 
>> 
>> jshell> MethodHandle handleRef = linker.downcallHandle(FunctionDescriptor.ofVoid(ValueLayout.ADDRESS));
>> handleRef ==> MethodHandle(MemorySegment,MemorySegment)void
>> 
>> jshell> handleRef.invoke(MemorySegment.ofAddress(1), null);
>> |  Exception java.lang.NullPointerException
>> |        at (#7:1)
>> 
>> 
>> Given what the impl does, to be fair I don't mind the NPE (it seems a good exception to throw if we're passing a raw `null`). But we should document it at such.
>> 
>> It also seems like the first parameter of the downcall has somewhat better checks (but still NPEs):
>> 
>> 
>> jshell> handleRef.invoke(null, MemorySegment.ofAddress(1));
>> |  Exception java.lang.NullPointerException
>> |        at Objects.requireNonNull (Objects.java:233)
>> |        at SharedUtils.checkSymbol (SharedUtils.java:351)
>> |        at (#8:1)
>> 
>> 
>> And:
>> 
>> 
>> jshell> handleRef.invoke(MemorySegment.NULL, MemorySegment.ofAddress(1));
>> |  Exception java.lang.IllegalArgumentException: Symbol is NULL: MemorySegment{ heapBase: Optional.empty address:0 limit: 0 }
>> |        at SharedUtils.checkSymbol (SharedUtils.java:353)
>> |        at (#9:1)
>> 
>> 
>> I think this last case is the _only_ one where IAE is warranted - as the role of the first parameter is special, and we can't tolerate a `MemorySegment::NULL` there. For all other reference parameters, the downcall handle should just check that they are non-null, and throw if so.
>
> The returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
> representing the target address of the foreign function is the {@link MemorySegment#NULL} address.
> The returned method handle will additionally throw {@link NullPointerException} if any parameter of type {@link MemorySegment} is {@code null}.

We should also NPE when the passed `SegmentAllocator` for struct returns is `null`, so for the last sentence I think this should say:


The returned method handle will additionally throw {@link NullPointerException} if any argument passed to it is {@code null}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1146264320

From bpb at openjdk.org  Thu Mar 23 18:03:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Mar 2023 18:03:40 GMT
Subject: Integrated: 4842457: (bf spec) Clarify meaning of
 "(optional operation)"
In-Reply-To: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
References: <ZGBL1Bz-lBIDRbZT8CNLGIPYC2wqeOX1flNAJbCvvZk=.b03b493f-6929-42ed-89a6-3017b41cd843@github.com>
Message-ID: <OmbBiEd-LnOC350mSJsg9mmeSkhSaqitY8elzaUt9V8=.44eabad7-7540-4cd7-93a2-77bbdf3e462f@github.com>

On Tue, 21 Mar 2023 16:43:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add some clarifying verbiage about optional operations to the type-specific buffer classes.

This pull request has now been integrated.

Changeset: 46cca1a4
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46cca1a4c52b47587e5e7e460744213f304b7ed3
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

4842457: (bf spec) Clarify meaning of "(optional operation)"

Reviewed-by: alanb

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

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

From lancea at openjdk.org  Thu Mar 23 18:52:07 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 23 Mar 2023 18:52:07 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v5]
In-Reply-To: <atRspgxDij2Hrly7iXoMXq5nsYlPKYZF-9wAJUvsqmY=.9976e631-2fea-4216-acc2-5bededc9cfae@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <atRspgxDij2Hrly7iXoMXq5nsYlPKYZF-9wAJUvsqmY=.9976e631-2fea-4216-acc2-5bededc9cfae@github.com>
Message-ID: <6O7Le0UP2_XGA5fVdF1vRShvA-FQFeQIeGTNVMbvGX0=.8375d465-da9b-4498-bd30-8172b19003c6@github.com>

On Fri, 17 Mar 2023 18:36:02 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
>> 
>> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
>> 
>> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
>> 
>> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add extra entry as a sanity check. Extract some constants for sizes and extract method makeOpaqueExtraField to allow some more in-depth commenting. Move extra field processing until after the LOC headers are written, such that this information only occurs in the CEN

I think this looks good overall.   Please see the comment below and then I can run the test one more time and you should be good to go

test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 191:

> 189:             e.setExtra(zip64);
> 190: 
> 191:             zo.finish(); // Write out CEN and END records

I might add one more entry after this one, perhaps with a compression method of DEFLATED

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12979#pullrequestreview-1355345890
PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1146677274

From bpb at openjdk.org  Thu Mar 23 20:06:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Mar 2023 20:06:56 GMT
Subject: RFR: 8304833: (fc) Remove dead code in
 sun.nio.ch.FileChannelImpl::implCloseChannel
Message-ID: <t2piA5vgymIJbBlOMeqsyQyhLQ-Yl3f3iXnWJ4xGmGI=.477e189a-0f21-4c6c-98b8-2762f9dd87b8@github.com>

Remove `fdAccess.close(fd)` branch in `implCloseChannel` as it is unreachable because exactly one of `parent` and `closer` can be non-`null`.

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

Commit messages:
 - 8304833: (fc) Remove dead code in sun.nio.ch.FileChannelImpl::implCloseChannel

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

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

From alanb at openjdk.org  Thu Mar 23 20:11:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Mar 2023 20:11:47 GMT
Subject: RFR: 8304833: (fc) Remove dead code in
 sun.nio.ch.FileChannelImpl::implCloseChannel
In-Reply-To: <t2piA5vgymIJbBlOMeqsyQyhLQ-Yl3f3iXnWJ4xGmGI=.477e189a-0f21-4c6c-98b8-2762f9dd87b8@github.com>
References: <t2piA5vgymIJbBlOMeqsyQyhLQ-Yl3f3iXnWJ4xGmGI=.477e189a-0f21-4c6c-98b8-2762f9dd87b8@github.com>
Message-ID: <8XNeEsGwIi4uqM_Hkm6Nhf89dN00oT9Pol9Fi5uIVks=.85c6782c-28b3-4c28-b6ca-aa38ccb5a9d6@github.com>

On Thu, 23 Mar 2023 19:58:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove `fdAccess.close(fd)` branch in `implCloseChannel` as it is unreachable because exactly one of `parent` and `closer` can be non-`null`.

This looks good, can you also check if parent can be changed from Object to Closeable, that would allow the cast to be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/13168#issuecomment-1481827132

From alanb at openjdk.org  Thu Mar 23 20:35:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Mar 2023 20:35:24 GMT
Subject: RFR: 8304833: (fc) Remove dead code in
 sun.nio.ch.FileChannelImpl::implCloseChannel [v2]
In-Reply-To: <XyNkcnCO-Ml7T0H8eFroqe-7tFeyuFQ_vAGCMgC83V4=.098834db-31e8-4bea-bf6a-aba855259994@github.com>
References: <t2piA5vgymIJbBlOMeqsyQyhLQ-Yl3f3iXnWJ4xGmGI=.477e189a-0f21-4c6c-98b8-2762f9dd87b8@github.com>
 <XyNkcnCO-Ml7T0H8eFroqe-7tFeyuFQ_vAGCMgC83V4=.098834db-31e8-4bea-bf6a-aba855259994@github.com>
Message-ID: <o7RPxbJxPF_zahYrUQKfjMsN7M-mye1Y6yJPkVbqqkY=.5af73ac8-a613-40f5-9f22-9193aa56f48b@github.com>

On Thu, 23 Mar 2023 20:31:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove `fdAccess.close(fd)` branch in `implCloseChannel` as it is unreachable because exactly one of `parent` and `closer` can be non-`null`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304833: Change type of parent to Closeable

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13168#pullrequestreview-1355532422

From bpb at openjdk.org  Thu Mar 23 20:35:26 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Mar 2023 20:35:26 GMT
Subject: RFR: 8304833: (fc) Remove dead code in
 sun.nio.ch.FileChannelImpl::implCloseChannel
In-Reply-To: <8XNeEsGwIi4uqM_Hkm6Nhf89dN00oT9Pol9Fi5uIVks=.85c6782c-28b3-4c28-b6ca-aa38ccb5a9d6@github.com>
References: <t2piA5vgymIJbBlOMeqsyQyhLQ-Yl3f3iXnWJ4xGmGI=.477e189a-0f21-4c6c-98b8-2762f9dd87b8@github.com>
 <8XNeEsGwIi4uqM_Hkm6Nhf89dN00oT9Pol9Fi5uIVks=.85c6782c-28b3-4c28-b6ca-aa38ccb5a9d6@github.com>
Message-ID: <KBHfbCCLJ7bvQpmcJhXLbH4EwWBzHYqo2i9xCIB0gzI=.893b329c-f1f7-44a8-be7f-91bef5ba4e7f@github.com>

On Thu, 23 Mar 2023 20:09:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> check if parent can be changed from Object to Closeable

Changed in 925f763d14d6b39f49bf58820f385a041dfae446. Clean + images build no problems seen.

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

PR Comment: https://git.openjdk.org/jdk/pull/13168#issuecomment-1481852548

From bpb at openjdk.org  Thu Mar 23 20:35:22 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Mar 2023 20:35:22 GMT
Subject: RFR: 8304833: (fc) Remove dead code in
 sun.nio.ch.FileChannelImpl::implCloseChannel [v2]
In-Reply-To: <t2piA5vgymIJbBlOMeqsyQyhLQ-Yl3f3iXnWJ4xGmGI=.477e189a-0f21-4c6c-98b8-2762f9dd87b8@github.com>
References: <t2piA5vgymIJbBlOMeqsyQyhLQ-Yl3f3iXnWJ4xGmGI=.477e189a-0f21-4c6c-98b8-2762f9dd87b8@github.com>
Message-ID: <XyNkcnCO-Ml7T0H8eFroqe-7tFeyuFQ_vAGCMgC83V4=.098834db-31e8-4bea-bf6a-aba855259994@github.com>

> Remove `fdAccess.close(fd)` branch in `implCloseChannel` as it is unreachable because exactly one of `parent` and `closer` can be non-`null`.

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

  8304833: Change type of parent to Closeable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13168/files
  - new: https://git.openjdk.org/jdk/pull/13168/files/3ffa59f1..925f763d

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

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

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

From naoto at openjdk.org  Fri Mar 24 01:56:31 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Mar 2023 01:56:31 GMT
Subject: RFR: 8272613: CharsetDecoder.decode(ByteBuffer) throws
 IllegalArgumentException
Message-ID: <_pL5Ln3AEY95ZQfPhn6ZjE3xNKE2uK3QzsgfZGZtjqA=.51eb0228-531b-4782-a979-7dfcaa92b238@github.com>

Addressing an integer overflow on decoding a large byte buffer. Now that the code only throws OOME if necessary, describing the fact with the `@throws` tag. A CSR for that is also drafted.

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

Commit messages:
 - Added OOME in the javadoc
 - cleanup
 - Added encoder tests, rename test case file
 - 8272613: CharsetDecoder.decode(ByteBuffer) throws IllegalArgumentException

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

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

From duke at openjdk.org  Fri Mar 24 07:34:24 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 24 Mar 2023 07:34:24 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v6]
In-Reply-To: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
Message-ID: <D-SIR4ouwV7NS8h_CxeIlSOh0rqB1lXI1LvaKO1fjlk=.8ae1dc3b-177e-4d25-b142-9eb2199b3939@github.com>

> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life.
> 
> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features  required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before  the 'Zip64 extended information'  field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF).
> 
> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros.
> 
> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing.

Eirik Bjorsnos 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:

 - Add a third DEFLATED entry to the test ZIP. Look up CEN offset from END header instead of skipping LOC headers. Add asserts that verifies that the ZIP has the expected entries.
 - Merge branch 'master' into loc-offset-zip64-sparse
 - Add extra entry as a sanity check. Extract some constants for sizes and extract method makeOpaqueExtraField to allow some more in-depth commenting. Move extra field processing until after the LOC headers are written, such that this information only occurs in the CEN
 - APPNOTE.txt actually specifies an 'unknown' tag, let's use that instead of 0x42
 - The Zip64 fields are all zero, we don't need to update them
 - Instead of making a big file to force Zip64, make a small file with a Zip64-formatted CEN header.
 - Remove accidentally introduced blank line
 - Merge branch 'master' into loc-offset-zip64-sparse
 - Rewrite TestLocOffsetFromZip64EF to create ZIP file using sparse ZipOutputStream instead of calling out to the ZIP command line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12979/files
  - new: https://git.openjdk.org/jdk/pull/12979/files/2fc841df..7949f7d8

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

  Stats: 84665 lines in 1081 files changed: 51366 ins; 22403 del; 10896 mod
  Patch: https://git.openjdk.org/jdk/pull/12979.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12979/head:pull/12979

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

From duke at openjdk.org  Fri Mar 24 07:34:28 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 24 Mar 2023 07:34:28 GMT
Subject: RFR: 8303972: Make
 test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip
 command line [v5]
In-Reply-To: <6O7Le0UP2_XGA5fVdF1vRShvA-FQFeQIeGTNVMbvGX0=.8375d465-da9b-4498-bd30-8172b19003c6@github.com>
References: <zRnyxtRbjzjOvLHoNeIdIgajGQZnQmI9kV2BmgAXrJc=.fa53af4e-3db9-4ba7-a481-24b60ad505a7@github.com>
 <atRspgxDij2Hrly7iXoMXq5nsYlPKYZF-9wAJUvsqmY=.9976e631-2fea-4216-acc2-5bededc9cfae@github.com>
 <6O7Le0UP2_XGA5fVdF1vRShvA-FQFeQIeGTNVMbvGX0=.8375d465-da9b-4498-bd30-8172b19003c6@github.com>
Message-ID: <i9B5JrnHt7D-5Px1QXapoZxHCKm11UUodhj4boiQ0eI=.84a8c3fa-c5e7-4af7-bba9-80c5a46b5e5d@github.com>

On Thu, 23 Mar 2023 18:46:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add extra entry as a sanity check. Extract some constants for sizes and extract method makeOpaqueExtraField to allow some more in-depth commenting. Move extra field processing until after the LOC headers are written, such that this information only occurs in the CEN
>
> test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 191:
> 
>> 189:             e.setExtra(zip64);
>> 190: 
>> 191:             zo.finish(); // Write out CEN and END records
> 
> I might add one more entry after this one, perhaps with a compression method of DEFLATED

I added a third DEFLATED entry, added asserts that ZipFile and ZipFileSystem finds the expected entries. The LOC traversal no longer works, so the CEN offset is now looked up from the EOC header instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1147207105

From duke at openjdk.org  Fri Mar 24 08:46:36 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 24 Mar 2023 08:46:36 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
Message-ID: <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>

On Wed, 22 Mar 2023 14:09:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadocs for Linker::captureStateLayout

src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 297:

> 295:         MethodType mtype = mh.type();
> 296:         int[] perms = new int[mtype.parameterCount()];
> 297:         MethodType swappedType = MethodType.methodType(mtype.returnType());

Instead?of `MethodType::appendParameterTypes(?)` (which?performs an?expensive?lookup of?a?new?cached `MethodType` value per?call), this?method should?instead use?a?`Class<?>[]` for?the?arguments, which?avoids that?overhead inside?a?loop:

	public static MethodHandle swapArguments(MethodHandle mh, int firstArg, int secondArg) {
		MethodType mtype = mh.type();
		int[] perms = new int[mtype.parameterCount()];
		Class<?>[] ptypes = new Class<?>[perms.length];
		for (int i = 0 ; i < perms.length ; i++) {
			int dst = i;
			if (i == firstArg) dst = secondArg;
			else if (i == secondArg) dst = firstArg;
			perms[i] = dst;
			ptypes[i] = mtype.parameterType(dst);
		}
		// This should use `JavaLangInvokeAccess` to invoke the internal
		// `MethodType.methodType(Class<?> rtype, Class<?>[] ptypes, boolean trusted)`
		// method with a `trusted` value of `true`:
		MethodType swappedType = MethodType.methodType(mtype.returnType(), ptypes);
		return permuteArguments(mh, swappedType, perms);
	}

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 61:

> 59:     static final MemorySegment VOID_TYPE = MemorySegment.ofAddress(ffi_type_void());
> 60:     static final short STRUCT_TAG = ffi_type_struct();
> 61:     private static final long SIZEOF_CIF = sizeofCif();

Won?t?calling `ffi_default_abi()` (and?the?other `ffi_*()`?methods) throw?`UnsatisfiedLinkError` if?`SUPPORTED`?is?`false`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1147259998
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1147267292

From shade at openjdk.org  Fri Mar 24 09:45:32 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Mar 2023 09:45:32 GMT
Subject: RFR: 8304591: (fs) UnixPath.stringValue need not be volatile [v2]
In-Reply-To: <Anj1GDgwgRPHifuV2ilZYdaXD2xeai0GZ06MV-6ty70=.ec6ed3bc-e73f-4c33-8de5-2e2b4361e2b4@github.com>
References: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
 <Anj1GDgwgRPHifuV2ilZYdaXD2xeai0GZ06MV-6ty70=.ec6ed3bc-e73f-4c33-8de5-2e2b4361e2b4@github.com>
Message-ID: <scutvR-Lpk058SGu1RXWd3euBCchtsCDc-wOkxf06X0=.c95ff771-cbec-445c-8b20-267d21765423@github.com>

On Tue, 21 Mar 2023 09:27:17 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `UnixPath.stringValue` can be computed by multiple threads safely as the actual value is the same, so the race is benign in this case.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13115#pullrequestreview-1356320057

From bpb at openjdk.org  Fri Mar 24 14:56:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Mar 2023 14:56:44 GMT
Subject: Integrated: 8304833: (fc) Remove dead code in
 sun.nio.ch.FileChannelImpl::implCloseChannel
In-Reply-To: <t2piA5vgymIJbBlOMeqsyQyhLQ-Yl3f3iXnWJ4xGmGI=.477e189a-0f21-4c6c-98b8-2762f9dd87b8@github.com>
References: <t2piA5vgymIJbBlOMeqsyQyhLQ-Yl3f3iXnWJ4xGmGI=.477e189a-0f21-4c6c-98b8-2762f9dd87b8@github.com>
Message-ID: <X-HOTfeyjquktNSnSB1KaH3rMU_tby0Y9D3h5z0Xgqo=.d5fc96c2-abb2-4977-a0a7-d9631e171a2d@github.com>

On Thu, 23 Mar 2023 19:58:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove `fdAccess.close(fd)` branch in `implCloseChannel` as it is unreachable because exactly one of `parent` and `closer` can be non-`null`.

This pull request has now been integrated.

Changeset: 9a8a60f7
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a8a60f7d6caae5b517b4284e10946ccc172ebd3
Stats:     13 lines in 1 file changed: 3 ins; 3 del; 7 mod

8304833: (fc) Remove dead code in sun.nio.ch.FileChannelImpl::implCloseChannel

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Mon Mar 27 12:58:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Mar 2023 12:58:29 GMT
Subject: RFR: 8272613: CharsetDecoder.decode(ByteBuffer) throws
 IllegalArgumentException
In-Reply-To: <_pL5Ln3AEY95ZQfPhn6ZjE3xNKE2uK3QzsgfZGZtjqA=.51eb0228-531b-4782-a979-7dfcaa92b238@github.com>
References: <_pL5Ln3AEY95ZQfPhn6ZjE3xNKE2uK3QzsgfZGZtjqA=.51eb0228-531b-4782-a979-7dfcaa92b238@github.com>
Message-ID: <s1wGcmlXlovzFk3vkL5YKYyezsVP46sZ1bTAtwaAWrw=.f3229c22-f724-4ec6-94ee-660bcd3311a3@github.com>

On Tue, 21 Mar 2023 22:40:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Addressing an integer overflow on decoding a large byte buffer. Now that the code only throws OOME if necessary, describing the fact with the `@throws` tag. A CSR for that is also drafted.

This change looks okay but I assume the test won't run on 32-bit due to the array size. It might need `@requires sun.arch.data.model == "64"`.

This change looks okay but I assume the test won't run on 32-bit due to the array size. It might need `@requires sun.arch.data.model == "64"`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13131#issuecomment-1485065367
PR Comment: https://git.openjdk.org/jdk/pull/13131#issuecomment-1485065518

From naoto at openjdk.org  Mon Mar 27 17:20:58 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 27 Mar 2023 17:20:58 GMT
Subject: RFR: 8272613: CharsetDecoder.decode(ByteBuffer) throws
 IllegalArgumentException [v2]
In-Reply-To: <_pL5Ln3AEY95ZQfPhn6ZjE3xNKE2uK3QzsgfZGZtjqA=.51eb0228-531b-4782-a979-7dfcaa92b238@github.com>
References: <_pL5Ln3AEY95ZQfPhn6ZjE3xNKE2uK3QzsgfZGZtjqA=.51eb0228-531b-4782-a979-7dfcaa92b238@github.com>
Message-ID: <XTzd-XJ-vIT_dmIF73opv-_YwCv-dy6958sKFmefqa0=.cfb25051-8cd0-4b0d-b2d6-08268e6eaa1c@github.com>

> Addressing an integer overflow on decoding a large byte buffer. Now that the code only throws OOME if necessary, describing the fact with the `@throws` tag. A CSR for that is also drafted.

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

  Limit arch to 64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13131/files
  - new: https://git.openjdk.org/jdk/pull/13131/files/c58054d1..31bb9701

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

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

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

From naoto at openjdk.org  Mon Mar 27 17:20:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 27 Mar 2023 17:20:59 GMT
Subject: RFR: 8272613: CharsetDecoder.decode(ByteBuffer) throws
 IllegalArgumentException
In-Reply-To: <s1wGcmlXlovzFk3vkL5YKYyezsVP46sZ1bTAtwaAWrw=.f3229c22-f724-4ec6-94ee-660bcd3311a3@github.com>
References: <_pL5Ln3AEY95ZQfPhn6ZjE3xNKE2uK3QzsgfZGZtjqA=.51eb0228-531b-4782-a979-7dfcaa92b238@github.com>
 <s1wGcmlXlovzFk3vkL5YKYyezsVP46sZ1bTAtwaAWrw=.f3229c22-f724-4ec6-94ee-660bcd3311a3@github.com>
Message-ID: <kZK9XVBu5neBSVivOZ40hgTlBmR7O8_Ex--aBTDZzp0=.0a7e7f51-a912-4da7-ab46-235893860c41@github.com>

On Mon, 27 Mar 2023 12:55:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change looks okay but I assume the test won't run on 32-bit due to the array size. It might need `@requires sun.arch.data.model == "64"`.

Thanks. Added the requirement to the test

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

PR Comment: https://git.openjdk.org/jdk/pull/13131#issuecomment-1485534487

From alanb at openjdk.org  Mon Mar 27 17:39:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Mar 2023 17:39:44 GMT
Subject: RFR: 8272613: CharsetDecoder.decode(ByteBuffer) throws
 IllegalArgumentException [v2]
In-Reply-To: <XTzd-XJ-vIT_dmIF73opv-_YwCv-dy6958sKFmefqa0=.cfb25051-8cd0-4b0d-b2d6-08268e6eaa1c@github.com>
References: <_pL5Ln3AEY95ZQfPhn6ZjE3xNKE2uK3QzsgfZGZtjqA=.51eb0228-531b-4782-a979-7dfcaa92b238@github.com>
 <XTzd-XJ-vIT_dmIF73opv-_YwCv-dy6958sKFmefqa0=.cfb25051-8cd0-4b0d-b2d6-08268e6eaa1c@github.com>
Message-ID: <oaL3tCnXqelkhEfkCIvbAPAuw-VyAc-sBVr4tUlMW9w=.2b1c52a2-c77d-43d5-9815-78b25ff997a9@github.com>

On Mon, 27 Mar 2023 17:20:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Addressing an integer overflow on decoding a large byte buffer. Now that the code only throws OOME if necessary, describing the fact with the `@throws` tag. A CSR for that is also drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Limit arch to 64

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13131#pullrequestreview-1359568852

From bpb at openjdk.org  Mon Mar 27 18:20:23 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Mar 2023 18:20:23 GMT
Subject: RFR: 8272613: CharsetDecoder.decode(ByteBuffer) throws
 IllegalArgumentException [v2]
In-Reply-To: <XTzd-XJ-vIT_dmIF73opv-_YwCv-dy6958sKFmefqa0=.cfb25051-8cd0-4b0d-b2d6-08268e6eaa1c@github.com>
References: <_pL5Ln3AEY95ZQfPhn6ZjE3xNKE2uK3QzsgfZGZtjqA=.51eb0228-531b-4782-a979-7dfcaa92b238@github.com>
 <XTzd-XJ-vIT_dmIF73opv-_YwCv-dy6958sKFmefqa0=.cfb25051-8cd0-4b0d-b2d6-08268e6eaa1c@github.com>
Message-ID: <tiQaowCgJCqEv4E4KP2htmvFDmLdA454wM5xX74u-kA=.2f2cdc8d-ce2b-4aa8-9152-7d0b1598f55f@github.com>

On Mon, 27 Mar 2023 17:20:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Addressing an integer overflow on decoding a large byte buffer. Now that the code only throws OOME if necessary, describing the fact with the `@throws` tag. A CSR for that is also drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Limit arch to 64

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13131#pullrequestreview-1359635780

From bpb at openjdk.org  Mon Mar 27 23:45:28 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Mar 2023 23:45:28 GMT
Subject: RFR: 4670339: (ch) Channels.newChannel(OutputStream) should flush
 stream on every write
Message-ID: <RW3l7zHsysV72cWD-93gpXBhPz5BnSrJ8KnEs42jR0E=.217c704c-e163-4a25-80c8-ca00e8a8807e@github.com>

Call `flush()` on the `OutputStream` before returning from `WritableByteChannelImpl::write`.

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

Commit messages:
 - 4670339: (ch) Channels.newChannel(OutputStream) should flush stream on every write

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

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

From alanb at openjdk.org  Tue Mar 28 07:12:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 07:12:28 GMT
Subject: RFR: 4670339: (ch) Channels.newChannel(OutputStream) should flush
 stream on every write
In-Reply-To: <RW3l7zHsysV72cWD-93gpXBhPz5BnSrJ8KnEs42jR0E=.217c704c-e163-4a25-80c8-ca00e8a8807e@github.com>
References: <RW3l7zHsysV72cWD-93gpXBhPz5BnSrJ8KnEs42jR0E=.217c704c-e163-4a25-80c8-ca00e8a8807e@github.com>
Message-ID: <lB6D-QLdY-bR7Fn3-N2PDt5pj3cviX-WF-JibWBIs4c=.9b577a52-b94b-48ca-b14f-121a0912d6f2@github.com>

On Mon, 27 Mar 2023 23:35:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Call `flush()` on the `OutputStream` before returning from `WritableByteChannelImpl::write`.

This changes long standing behavior and may impact performance when the output stream is buffered. Is there a compelling reason to change the behavior? If so then maybe other options could be explored, `newChannel(OutputStream, boolean autoFlush)` or just documenting that automatic flushing can be done by wrapping the output stream.

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

PR Comment: https://git.openjdk.org/jdk/pull/13198#issuecomment-1486330070

From pminborg at openjdk.org  Tue Mar 28 10:03:37 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:03:37 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
Message-ID: <HjBAtHd8xcylCVfDPjKgabKcPG2LIy4egD5iUMLz5rg=.ae4edf98-987c-483a-8f6b-f8c0c0f594a0@github.com>

On Fri, 24 Mar 2023 08:35:06 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 297:
> 
>> 295:         MethodType mtype = mh.type();
>> 296:         int[] perms = new int[mtype.parameterCount()];
>> 297:         MethodType swappedType = MethodType.methodType(mtype.returnType());
> 
> Instead?of `MethodType::appendParameterTypes(?)` (which?performs an?expensive?lookup of?a?new?cached `MethodType` value per?call), this?method should?instead use?a?`Class<?>[]` for?the?arguments, which?avoids that?overhead inside?a?loop:
> 
> 	public static MethodHandle swapArguments(MethodHandle mh, int firstArg, int secondArg) {
> 		MethodType mtype = mh.type();
> 		int[] perms = new int[mtype.parameterCount()];
> 		Class<?>[] ptypes = new Class<?>[perms.length];
> 		for (int i = 0 ; i < perms.length ; i++) {
> 			int dst = i;
> 			if (i == firstArg) dst = secondArg;
> 			else if (i == secondArg) dst = firstArg;
> 			perms[i] = dst;
> 			ptypes[i] = mtype.parameterType(dst);
> 		}
> 		// This should use `JavaLangInvokeAccess` to invoke the internal
> 		// `MethodType.methodType(Class<?> rtype, Class<?>[] ptypes, boolean trusted)`
> 		// method with a `trusted` value of `true`:
> 		MethodType swappedType = MethodType.methodType(mtype.returnType(), ptypes);
> 		return permuteArguments(mh, swappedType, perms);
> 	}

Thanks for this enhancement proposal. I hope you do not mind me asking if you could file a separate issue about this where you describe the above? We can then merge that proposal independent of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150341545

From pminborg at openjdk.org  Tue Mar 28 10:15:13 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:15:13 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v9]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <w6e1zS2kGsJZdVYxHoPxjvfP5fnvIaQdIuYgpCOBvbQ=.eb5241fe-0cc2-4bb1-bbab-278e6aec19b1@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

 - Make fallbacklinker.c consistent with downcallLinker.cpp
 - Add bug number
 - Use @return
 - Update Linker.downcallHandle() javadoc
 - Fix typos in Arena
 - Make checking method handle zero case
 - Add snippet to Linker.Option.captureStateLayout()
 - Apply RISCV port patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/6df28a78..3dab13da

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

  Stats: 125 lines in 13 files changed: 39 ins; 20 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

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

From pminborg at openjdk.org  Tue Mar 28 10:15:19 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:15:19 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
Message-ID: <82NY-GyOk1U9SLOqfPdRjwT_ypxKVEJx0JItDO0VXik=.5b5c7184-6d6d-4627-8803-03461a2297bc@github.com>

On Fri, 24 Mar 2023 08:42:37 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 61:
> 
>> 59:     static final MemorySegment VOID_TYPE = MemorySegment.ofAddress(ffi_type_void());
>> 60:     static final short STRUCT_TAG = ffi_type_struct();
>> 61:     private static final long SIZEOF_CIF = sizeofCif();
> 
> Won?t?calling `ffi_default_abi()` (and?the?other `ffi_*()`?methods) throw?`UnsatisfiedLinkError` if?`SUPPORTED`?is?`false`?

I think so too. How do we guard agains this @JornVernee ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150350299

From pminborg at openjdk.org  Tue Mar 28 10:56:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:56:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge with master
 - Make fallbacklinker.c consistent with downcallLinker.cpp
 - Add bug number
 - Use @return
 - Update Linker.downcallHandle() javadoc
 - Fix typos in Arena
 - Make checking method handle zero case
 - Add snippet to Linker.Option.captureStateLayout()
 - Apply RISCV port patch
 - Improve javadocs for Linker::captureStateLayout
 - ... and 12 more: https://git.openjdk.org/jdk/compare/cddaf686...bc29c6fc

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

Changes: https://git.openjdk.org/jdk/pull/13079/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=09
  Stats: 13027 lines in 267 files changed: 5006 ins; 6015 del; 2006 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

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

From mcimadamore at openjdk.org  Tue Mar 28 11:03:39 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 28 Mar 2023 11:03:39 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
Message-ID: <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>

On Tue, 28 Mar 2023 10:56:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge with master
>  - Make fallbacklinker.c consistent with downcallLinker.cpp
>  - Add bug number
>  - Use @return
>  - Update Linker.downcallHandle() javadoc
>  - Fix typos in Arena
>  - Make checking method handle zero case
>  - Add snippet to Linker.Option.captureStateLayout()
>  - Apply RISCV port patch
>  - Improve javadocs for Linker::captureStateLayout
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/cddaf686...bc29c6fc

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2310:

> 2308:         /**
> 2309:          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
> 2310:          * modelled by this scope}. In that case, it is always the case that

This brace (after `scope`) seems spurious?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150408522

From stsypanov at openjdk.org  Tue Mar 28 11:17:51 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 28 Mar 2023 11:17:51 GMT
Subject: Integrated: 8304591: (fs) UnixPath.stringValue need not be volatile
In-Reply-To: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
References: <d23YJjiR8wOPXXfSwoXlppBdzb_63QhiW977i2E0jGI=.a91ddf85-3de2-4b3e-a9b3-58b8a6e3ba79@github.com>
Message-ID: <FP25OhZZUCRVrMmVIfMgBvItkwLSgKevptF6W8q9C-s=.eb256606-d1b0-4fe1-98c0-8e17e6d953e1@github.com>

On Tue, 21 Mar 2023 09:00:19 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> `UnixPath.stringValue` can be computed by multiple threads safely as the actual value is the same, so the race is benign in this case.

This pull request has now been integrated.

Changeset: 395a4ce0
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/395a4ce0dd4181bbb4bc0888038309901ebf8fea
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8304591: (fs) UnixPath.stringValue need not be volatile

Reviewed-by: alanb, bpb, shade

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

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

From jvernee at openjdk.org  Tue Mar 28 12:39:41 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 12:39:41 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>
Message-ID: <X6m7dliUoUzaubf5bXkaCwEmCZaz-d0vomdgneJslsQ=.88804c90-b3dc-4f45-b740-55c41ee57d39@github.com>

On Tue, 28 Mar 2023 11:00:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge with master
>>  - Make fallbacklinker.c consistent with downcallLinker.cpp
>>  - Add bug number
>>  - Use @return
>>  - Update Linker.downcallHandle() javadoc
>>  - Fix typos in Arena
>>  - Make checking method handle zero case
>>  - Add snippet to Linker.Option.captureStateLayout()
>>  - Apply RISCV port patch
>>  - Improve javadocs for Linker::captureStateLayout
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/cddaf686...bc29c6fc
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2310:
> 
>> 2308:         /**
>> 2309:          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>> 2310:          * modelled by this scope}. In that case, it is always the case that
> 
> This brace (after `scope`) seems spurious?

It's to close the text span for the `{@return`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150540008

From pminborg at openjdk.org  Tue Mar 28 13:06:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:06:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v11]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <ESoZsip9RCCAhw-45qti9kL5IwXhzVzks-TRHfedUyI=.47a3b8d4-6276-45b1-b167-d9d0caffdaf3@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

  Update copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/bc29c6fc..e7471d02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=09-10

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

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

From pminborg at openjdk.org  Tue Mar 28 13:14:09 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:14:09 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v12]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <ULiv3xz4T-tuemI4RMgY9p0l8qWFdk5pI_p3sj2AKbc=.82f3043a-6f58-468e-80be-403f49aa2e3c@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

  Fix copyrigth year issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/e7471d02..24bea62e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=10-11

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

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

From pminborg at openjdk.org  Tue Mar 28 13:14:10 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:14:10 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <X6m7dliUoUzaubf5bXkaCwEmCZaz-d0vomdgneJslsQ=.88804c90-b3dc-4f45-b740-55c41ee57d39@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>
 <X6m7dliUoUzaubf5bXkaCwEmCZaz-d0vomdgneJslsQ=.88804c90-b3dc-4f45-b740-55c41ee57d39@github.com>
Message-ID: <ZEd8fiQ4rlYXBX6S0CjRZNfP9L5CN2us10z_wAKzKgk=.9b27e5f5-33fe-4ab3-810c-62054002732d@github.com>

On Tue, 28 Mar 2023 12:36:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2310:
>> 
>>> 2308:         /**
>>> 2309:          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>>> 2310:          * modelled by this scope}. In that case, it is always the case that
>> 
>> This brace (after `scope`) seems spurious?
>
> It's to close the text span for the `{@return`

<img width="315" alt="image" src="https://user-images.githubusercontent.com/7457876/228246205-ff2730cb-610f-4673-aa30-d110845a34fc.png">

It belongs to the opening brace for `{@return`. Hard to see with other curls in between.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150584776

From pminborg at openjdk.org  Tue Mar 28 13:14:10 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:14:10 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <ZEd8fiQ4rlYXBX6S0CjRZNfP9L5CN2us10z_wAKzKgk=.9b27e5f5-33fe-4ab3-810c-62054002732d@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>
 <X6m7dliUoUzaubf5bXkaCwEmCZaz-d0vomdgneJslsQ=.88804c90-b3dc-4f45-b740-55c41ee57d39@github.com>
 <ZEd8fiQ4rlYXBX6S0CjRZNfP9L5CN2us10z_wAKzKgk=.9b27e5f5-33fe-4ab3-810c-62054002732d@github.com>
Message-ID: <moZMRwCK2LuGQxsA5p7iNalukw8fn_wf39P6qXiVd3U=.20b3f0ed-590a-4daf-bf80-651d96200b09@github.com>

On Tue, 28 Mar 2023 13:08:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> It's to close the text span for the `{@return`
>
> <img width="315" alt="image" src="https://user-images.githubusercontent.com/7457876/228246205-ff2730cb-610f-4673-aa30-d110845a34fc.png">
> 
> It belongs to the opening brace for `{@return`. Hard to see with other curls in between.

I would have written:


{@return if the provided object ...


`true` seams redundant to me but I know this style is used within the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150586639

From jvernee at openjdk.org  Tue Mar 28 13:53:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 13:53:27 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <82NY-GyOk1U9SLOqfPdRjwT_ypxKVEJx0JItDO0VXik=.5b5c7184-6d6d-4627-8803-03461a2297bc@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
 <82NY-GyOk1U9SLOqfPdRjwT_ypxKVEJx0JItDO0VXik=.5b5c7184-6d6d-4627-8803-03461a2297bc@github.com>
Message-ID: <FCt-M6MolO72GDY7AP-MFnzmx_Mf1Bi5eDc_UvKafLY=.a784cea2-376a-49f9-9fb4-e090225cfa87@github.com>

On Tue, 28 Mar 2023 10:07:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 61:
>> 
>>> 59:     static final MemorySegment VOID_TYPE = MemorySegment.ofAddress(ffi_type_void());
>>> 60:     static final short STRUCT_TAG = ffi_type_struct();
>>> 61:     private static final long SIZEOF_CIF = sizeofCif();
>> 
>> Won?t?calling `ffi_default_abi()` (and?the?other `ffi_*()`?methods) throw?`UnsatisfiedLinkError` if?`SUPPORTED`?is?`false`?
>
> I think so too. How do we guard agains this @JornVernee ?

You're right. Fix here: https://github.com/minborg/jdk/pull/1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150645955

From jvernee at openjdk.org  Tue Mar 28 13:53:29 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 13:53:29 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v12]
In-Reply-To: <ULiv3xz4T-tuemI4RMgY9p0l8qWFdk5pI_p3sj2AKbc=.82f3043a-6f58-468e-80be-403f49aa2e3c@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ULiv3xz4T-tuemI4RMgY9p0l8qWFdk5pI_p3sj2AKbc=.82f3043a-6f58-468e-80be-403f49aa2e3c@github.com>
Message-ID: <W0dTKlyYvQfBD-Ybxvow74vzQMCw4XA9rZOpaZYRV9g=.8684d12e-776b-4ace-8c85-e303a43a68b7@github.com>

On Tue, 28 Mar 2023 13:14:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyrigth year issues

src/java.base/share/classes/jdk/internal/vm/ForeignLinkerSupport.java line 52:

> 50:         }
> 51:     }
> 52: 

I also noticed that this method is not used and can be removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150647849

From mcimadamore at openjdk.org  Tue Mar 28 14:11:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 28 Mar 2023 14:11:51 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <moZMRwCK2LuGQxsA5p7iNalukw8fn_wf39P6qXiVd3U=.20b3f0ed-590a-4daf-bf80-651d96200b09@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>
 <X6m7dliUoUzaubf5bXkaCwEmCZaz-d0vomdgneJslsQ=.88804c90-b3dc-4f45-b740-55c41ee57d39@github.com>
 <ZEd8fiQ4rlYXBX6S0CjRZNfP9L5CN2us10z_wAKzKgk=.9b27e5f5-33fe-4ab3-810c-62054002732d@github.com>
 <moZMRwCK2LuGQxsA5p7iNalukw8fn_wf39P6qXiVd3U=.20b3f0ed-590a-4daf-bf80-651d96200b09@github.com>
Message-ID: <2k3-c9kKwEOuBAu-fO4a1xSmATAR3kGECTYUQafoSy4=.1ed80abc-a8ae-4151-bcfa-52cdd2855ead@github.com>

On Tue, 28 Mar 2023 13:09:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> <img width="315" alt="image" src="https://user-images.githubusercontent.com/7457876/228246205-ff2730cb-610f-4673-aa30-d110845a34fc.png">
>> 
>> It belongs to the opening brace for `{@return`. Hard to see with other curls in between.
>
> I would have written:
> 
> 
> {@return if the provided object ...
> 
> 
> `true` seams redundant to me but I know this style is used within the JDK.

Whoops - thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150685611

From bpb at openjdk.org  Tue Mar 28 17:06:39 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 28 Mar 2023 17:06:39 GMT
Subject: RFR: 4670339: (ch) Channels.newChannel(OutputStream) should flush
 stream on every write [v2]
In-Reply-To: <RW3l7zHsysV72cWD-93gpXBhPz5BnSrJ8KnEs42jR0E=.217c704c-e163-4a25-80c8-ca00e8a8807e@github.com>
References: <RW3l7zHsysV72cWD-93gpXBhPz5BnSrJ8KnEs42jR0E=.217c704c-e163-4a25-80c8-ca00e8a8807e@github.com>
Message-ID: <bY58IbkNSUod1jywB2DuQJKn1AHXQX-rbHG_UOg2n_A=.cc2b9526-f6e9-4d1e-82d2-a4b33ede9caf@github.com>

> Call `flush()` on the `OutputStream` before returning from `WritableByteChannelImpl::write`.

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

  4670339: Make WritableByteChannelImpl Flushable; add newChannel(OutputStream,boolean)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13198/files
  - new: https://git.openjdk.org/jdk/pull/13198/files/009c022d..9967977e

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

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

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

From naoto at openjdk.org  Tue Mar 28 18:33:24 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Mar 2023 18:33:24 GMT
Subject: RFR: 8304840: Dangling `CharacterCodingException` in a few javadoc
 descriptions
Message-ID: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>

Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.

![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

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

Commit messages:
 - Duplicate descriptions in CharacterCodingException
 - 8304840: Dangling `CharacterCodingException` in a few javadoc descriptions

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

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

From alanb at openjdk.org  Tue Mar 28 19:19:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 19:19:30 GMT
Subject: RFR: 8304840: Dangling `CharacterCodingException` in a few javadoc
 descriptions
In-Reply-To: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
References: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
Message-ID: <SuqVPm6vek4yagO8hoEsum2cTZWhLgM8z1ViQFxupk4=.16770c37-5660-40d6-adf9-4a8faa8b39bc@github.com>

On Tue, 28 Mar 2023 18:25:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

It means the descriptions are duplicate but I think better than making reader be concerned about other conditions that aren't specified. So I think this is okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13214#pullrequestreview-1361763158

From iris at openjdk.org  Tue Mar 28 19:40:32 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 28 Mar 2023 19:40:32 GMT
Subject: RFR: 8304840: Dangling `CharacterCodingException` in a few javadoc
 descriptions
In-Reply-To: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
References: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
Message-ID: <FjOYkzrE2UzwW70RVflIIDKrF2OvZUvb4Wa4801iGfY=.c9937151-57e5-4729-a132-243d91f5ae75@github.com>

On Tue, 28 Mar 2023 18:25:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

Associated CSR also Reviewed.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13214#pullrequestreview-1361791244

From rriggs at openjdk.org  Tue Mar 28 19:46:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Mar 2023 19:46:35 GMT
Subject: RFR: 8304840: Dangling `CharacterCodingException` in a few javadoc
 descriptions
In-Reply-To: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
References: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
Message-ID: <9ciZnawfhUvvH3Kierv1zLf526z1R9q7huHKy7vonio=.72ce3961-b42f-4b9f-82c6-c9b872af460c@github.com>

On Tue, 28 Mar 2023 18:25:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13214#pullrequestreview-1361798141

From duke at openjdk.org  Tue Mar 28 20:41:42 2023
From: duke at openjdk.org (duke)
Date: Tue, 28 Mar 2023 20:41:42 GMT
Subject: Withdrawn: 8298658: Platform-specific type leaks to platform
 independent code.
In-Reply-To: <qdh5-u8kCzgT8vJMWcfjyYT9RFBnEs6XsWQBLor_tJo=.5d4a52bf-24a3-40d2-b2fe-7df24de40548@github.com>
References: <qdh5-u8kCzgT8vJMWcfjyYT9RFBnEs6XsWQBLor_tJo=.5d4a52bf-24a3-40d2-b2fe-7df24de40548@github.com>
Message-ID: <s9zDJmiLDtWMzr2iZJZox2z9jTC9Qw5sH1gv4rhw5L0=.6ad2ade2-4619-4637-973f-c7f10bd297cf@github.com>

On Wed, 14 Dec 2022 13:37:32 GMT, Alfonso? Peterssen <duke at openjdk.org> wrote:

> This is not a cosmetic change, it enforces the isolation of platform-specific code from the user-facing API.
> 
> `sun.nio.fs.DefaultFileSystemProvider#instance()` has a platform-specific return type. This makes the platform-independent `java.nio.file.FileSystems.DefaultFileSystemHolder#getDefaultProvider()` have a platform-dependent call e.g. INVOKESTATIC with different signatures.
> 
> The platform-specific return types were introduced in [JDK-8213406](https://bugs.openjdk.org/browse/JDK-8213406), the common SPI type was used before. There's no reason to leak types to platform-independent code, except for tests, which could just cast.
> 
> This change is motivated by [Espresso](https://github.com/oracle/graal/tree/master/espresso), a meta-circular, spec-compliant JVM written in Java. Espresso aims to provide a custom Java IO/NIO implementation on top of any vanilla JDK as a viable alternative to the imminent removal of `SecurityManager`.

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Wed Mar 29 00:01:22 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 00:01:22 GMT
Subject: RFR: 8303260: (fc) FileChannel::transferFrom should support
 position > size() [v4]
In-Reply-To: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
References: <3K-UVcqh0FsqxNOG5w6mFgyr56_fnD-id2_nRUbOnI0=.f3608ba3-057f-4726-83a9-0a4e509e7844@github.com>
Message-ID: <EWe5kVm50gDQA94FKCKbcOReC16HW6g87vnDT6PY3Z8=.abcbd0d2-d461-4e5f-98b5-2cf53a1d2d96@github.com>

> Enhance `FileChannel::transferFrom` to extend the channel's file if `position > size()`. This is consistent with `FileChannel::write(ByteBuffer, long)`.

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

  8303260: Increment copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12797/files
  - new: https://git.openjdk.org/jdk/pull/12797/files/085746fa..27aa2a36

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

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

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

From bpb at openjdk.org  Wed Mar 29 00:40:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 00:40:08 GMT
Subject: RFR: 8202110: (fs) Default file system provider should load
 UnixNativeDispatcher lazily [v2]
In-Reply-To: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
Message-ID: <xvQFxMMDpY4p16J3FtXyZrsVkYWEoQov9d6gJqkyrQY=.11afe4ec-617a-4363-9cd1-6a6e216b8957@github.com>

> Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.

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

  8202110: Remove undocumented sun.nio.fs.chdirAllowed property and dependent code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13132/files
  - new: https://git.openjdk.org/jdk/pull/13132/files/ea5ae7b8..267f9a69

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

  Stats: 66 lines in 7 files changed: 5 ins; 45 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/13132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13132/head:pull/13132

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

From bpb at openjdk.org  Wed Mar 29 00:40:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 00:40:08 GMT
Subject: RFR: 8202110: (fs) Default file system provider should load
 UnixNativeDispatcher lazily [v2]
In-Reply-To: <X2i8PXrg6VOE6zUH7GjX95fgbUX3In-PoIULYp8u6AI=.498cab76-fcfb-4bd9-8015-7029b7688468@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
 <X2i8PXrg6VOE6zUH7GjX95fgbUX3In-PoIULYp8u6AI=.498cab76-fcfb-4bd9-8015-7029b7688468@github.com>
Message-ID: <fHUgHQUeBc6KDivhCYtKcCUcPYKwo043yY5hG6jNWZw=.7602bc9d-059f-408b-98b5-96cb192441c2@github.com>

On Wed, 22 Mar 2023 14:12:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8202110: Remove undocumented sun.nio.fs.chdirAllowed property and dependent code
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 123:
> 
>> 121:                 this.needToResolveAgainstDefaultDirectory = !defaultIsCwd;
>> 122:             }
>> 123:         }
> 
> Making needToResolveAgainstDefaultDirectory a tri-state is a bit ugly. If we really need to defer this then it might be better to just move the field to Holder class, that way this method would return holder.needToResolveAgainstDefaultDirectory.

The use of `needToResolveAgainstDefaultDirectory` is removed in 267f9a699410cc39fefeedd9623eae756f4e1fcd.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13132#discussion_r1151281805

From jpai at openjdk.org  Wed Mar 29 05:13:30 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Mar 2023 05:13:30 GMT
Subject: RFR: 8304840: Dangling `CharacterCodingException` in a few javadoc
 descriptions
In-Reply-To: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
References: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
Message-ID: <FVglHPGnl2ufFHk55qNSZz4Pdh2nXJeYMJZhuoHKsZE=.4ab6b75c-a685-4e25-b8cf-d3a9b397f691@github.com>

On Tue, 28 Mar 2023 18:25:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13214#pullrequestreview-1362262058

From alanb at openjdk.org  Wed Mar 29 06:56:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 06:56:41 GMT
Subject: RFR: 8202110: (fs) Default file system provider should load
 UnixNativeDispatcher lazily [v2]
In-Reply-To: <xvQFxMMDpY4p16J3FtXyZrsVkYWEoQov9d6gJqkyrQY=.11afe4ec-617a-4363-9cd1-6a6e216b8957@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
 <xvQFxMMDpY4p16J3FtXyZrsVkYWEoQov9d6gJqkyrQY=.11afe4ec-617a-4363-9cd1-6a6e216b8957@github.com>
Message-ID: <X1Nu0-zRmjlNkLy2UmDZ-kqSOfKobRn6s6_Xizr1zp8=.6ea1a0fc-0aa0-4a20-a43c-67707dbd75f3@github.com>

On Wed, 29 Mar 2023 00:40:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8202110: Remove undocumented sun.nio.fs.chdirAllowed property and dependent code

The updated version looks to be a good cleanup but there is a orphaned "dir" parameter now. I think the starting point will be UnixFileSystemProvider and WindowsFileSystemProvider where you can drop the lookup of user.dir and then the cleanup will flow from there.

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 81:

> 79:     // package-private
> 80:     UnixFileSystem(UnixFileSystemProvider provider) {
> 81:         String dir = SystemProps.initProperties().get("user.dir");

The original code used `StaticProperty.userDir()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13132#issuecomment-1488038397
PR Review Comment: https://git.openjdk.org/jdk/pull/13132#discussion_r1151467995

From aturbanov at openjdk.org  Wed Mar 29 07:43:31 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 29 Mar 2023 07:43:31 GMT
Subject: RFR: 4670339: (ch) Channels.newChannel(OutputStream) should flush
 stream on every write [v2]
In-Reply-To: <bY58IbkNSUod1jywB2DuQJKn1AHXQX-rbHG_UOg2n_A=.cc2b9526-f6e9-4d1e-82d2-a4b33ede9caf@github.com>
References: <RW3l7zHsysV72cWD-93gpXBhPz5BnSrJ8KnEs42jR0E=.217c704c-e163-4a25-80c8-ca00e8a8807e@github.com>
 <bY58IbkNSUod1jywB2DuQJKn1AHXQX-rbHG_UOg2n_A=.cc2b9526-f6e9-4d1e-82d2-a4b33ede9caf@github.com>
Message-ID: <X5Zuv3T-msecR_BX5vRqLn1u_GEQI01buR8PZevuzwo=.194f40ac-f068-4165-a787-1aeba62f4bb6@github.com>

On Tue, 28 Mar 2023 17:06:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Call `flush()` on the `OutputStream` before returning from `WritableByteChannelImpl::write`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4670339: Make WritableByteChannelImpl Flushable; add newChannel(OutputStream,boolean)

test/jdk/java/nio/channels/Channels/Basic.java line 306:

> 304:         ByteArrayOutputStream baos = new ByteArrayOutputStream(size);
> 305:         try (BufferedOutputStream bos = new BufferedOutputStream(baos, size);
> 306:              WritableByteChannel wbc = Channels.newChannel(bos, true);) {

Suggestion:

             WritableByteChannel wbc = Channels.newChannel(bos, true)) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13198#discussion_r1151516729

From alanb at openjdk.org  Wed Mar 29 08:05:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 08:05:58 GMT
Subject: RFR: 4670339: (ch) Channels.newChannel(OutputStream) should flush
 stream on every write [v2]
In-Reply-To: <bY58IbkNSUod1jywB2DuQJKn1AHXQX-rbHG_UOg2n_A=.cc2b9526-f6e9-4d1e-82d2-a4b33ede9caf@github.com>
References: <RW3l7zHsysV72cWD-93gpXBhPz5BnSrJ8KnEs42jR0E=.217c704c-e163-4a25-80c8-ca00e8a8807e@github.com>
 <bY58IbkNSUod1jywB2DuQJKn1AHXQX-rbHG_UOg2n_A=.cc2b9526-f6e9-4d1e-82d2-a4b33ede9caf@github.com>
Message-ID: <BDvPA6_I48qTIWnSqy1mXOOJ9tLcOrEkV6oQiMAQNlw=.f70f4dd8-458a-4d0c-bc9f-e317482ae7a0@github.com>

On Tue, 28 Mar 2023 17:06:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Call `flush()` on the `OutputStream` before returning from `WritableByteChannelImpl::write`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4670339: Make WritableByteChannelImpl Flushable; add newChannel(OutputStream,boolean)

src/java.base/share/classes/java/nio/channels/Channels.java line 347:

> 345:      * its I/O operations to the given stream.  Closing the channel will in
> 346:      * turn cause the stream to be closed.  The returned channel implements
> 347:      * {@linkplain Flushable}; flushing the channel will flush the stream. </p>

This was just a suggestion to try but I think it's a bit too weird so I would drop that. 

I think the main thing we need to decide is whether a factory method for an auto-flushing output stream is useful to have to not. Maybe we should try to survey the usages of this factory method to see if there is much usage and in what contexts.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13198#discussion_r1151541311

From pminborg at openjdk.org  Wed Mar 29 08:21:00 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 08:21:00 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v13]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <AimZBwprTTvzCtc5pZtCqEQluMT2X_C7X2Guf5dPsr8=.77d1c738-f62e-4f8d-930e-5c9bbce65d2b@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

  Remove unused method and declare class final

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/24bea62e..54e49e0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=11-12

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

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

From pminborg at openjdk.org  Wed Mar 29 08:25:17 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 08:25:17 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v14]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <E3Su9nxPX8s8vIaqXwbcelol_otP2X5LhOgHbTJrLA8=.2ad7bc0f-0c30-443e-bb4e-e7ab7f7bc4a6@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

 - Merge pull request #1 from JornVernee/Fix_ULE
   
   Fix ULE when intializing LibFallback
 - fix ULE when intializing LibFallback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/54e49e0a..846eaf30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=12-13

  Stats: 48 lines in 4 files changed: 20 ins; 1 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

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

From pminborg at openjdk.org  Wed Mar 29 08:55:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 08:55:08 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

  Cleanup finality

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/846eaf30..c787a282

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=13-14

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

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

From jvernee at openjdk.org  Wed Mar 29 14:45:11 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Mar 2023 14:45:11 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
Message-ID: <dSdHosd_vI2VCf93TrT2VcmmP_Yq9DyxPmwked_8aYg=.7802362d-5ecc-4f1d-a069-4cf6fff6fb49@github.com>

On Wed, 29 Mar 2023 08:55:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup finality

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13079#pullrequestreview-1363295684

From bpb at openjdk.org  Wed Mar 29 15:06:36 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 15:06:36 GMT
Subject: RFR: 8202110: (fs) Default file system provider should load
 UnixNativeDispatcher lazily [v2]
In-Reply-To: <X1Nu0-zRmjlNkLy2UmDZ-kqSOfKobRn6s6_Xizr1zp8=.6ea1a0fc-0aa0-4a20-a43c-67707dbd75f3@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
 <xvQFxMMDpY4p16J3FtXyZrsVkYWEoQov9d6gJqkyrQY=.11afe4ec-617a-4363-9cd1-6a6e216b8957@github.com>
 <X1Nu0-zRmjlNkLy2UmDZ-kqSOfKobRn6s6_Xizr1zp8=.6ea1a0fc-0aa0-4a20-a43c-67707dbd75f3@github.com>
Message-ID: <f6JfZh6SBfV_rxLPBhCqYVHAalhg2huVJ1GlJKyav2E=.1f5ba9ff-4527-4669-8170-b32d467c81f8@github.com>

On Wed, 29 Mar 2023 06:54:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The updated version looks to be a good cleanup but there is a orphaned "dir" parameter now.

Right. I left it there intentionally with a view to later cleanup.

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

PR Comment: https://git.openjdk.org/jdk/pull/13132#issuecomment-1488802229

From naoto at openjdk.org  Wed Mar 29 16:12:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Mar 2023 16:12:48 GMT
Subject: Integrated: 8272613: CharsetDecoder.decode(ByteBuffer) throws
 IllegalArgumentException
In-Reply-To: <_pL5Ln3AEY95ZQfPhn6ZjE3xNKE2uK3QzsgfZGZtjqA=.51eb0228-531b-4782-a979-7dfcaa92b238@github.com>
References: <_pL5Ln3AEY95ZQfPhn6ZjE3xNKE2uK3QzsgfZGZtjqA=.51eb0228-531b-4782-a979-7dfcaa92b238@github.com>
Message-ID: <ssr6M8RDbaiaiPHiJF72qUOIRR1igJD38bhNeERpG7k=.e7410657-86ca-4d14-90a3-ad801819c045@github.com>

On Tue, 21 Mar 2023 22:40:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Addressing an integer overflow on decoding a large byte buffer. Now that the code only throws OOME if necessary, describing the fact with the `@throws` tag. A CSR for that is also drafted.

This pull request has now been integrated.

Changeset: f07decb7
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f07decb74b525072cf035b1e11569d43390952ed
Stats:     98 lines in 2 files changed: 95 ins; 0 del; 3 mod

8272613: CharsetDecoder.decode(ByteBuffer) throws IllegalArgumentException

Reviewed-by: alanb, bpb

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

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

From naoto at openjdk.org  Wed Mar 29 16:23:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Mar 2023 16:23:37 GMT
Subject: RFR: 8304840: Dangling `CharacterCodingException` in a few javadoc
 descriptions [v2]
In-Reply-To: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
References: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
Message-ID: <p19CNkYZPrG9jLppSfgY4ULr1EkjH-D5Dkd4fZfL-Bg=.aab4e8fd-b32c-4b94-b244-4d069c008c4f@github.com>

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

Naoto Sato 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 JDK-8304840-CharacterCodingException
 - Duplicate descriptions in CharacterCodingException
 - 8304840: Dangling `CharacterCodingException` in a few javadoc descriptions

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

Changes: https://git.openjdk.org/jdk/pull/13214/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13214&range=01
  Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13214.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13214/head:pull/13214

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

From naoto at openjdk.org  Wed Mar 29 16:23:39 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Mar 2023 16:23:39 GMT
Subject: Integrated: 8304840: Dangling `CharacterCodingException` in a few
 javadoc descriptions
In-Reply-To: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
References: <wCrQuEVWN9jhgIT8iCILQwocrfVzIDr8B04C7LPb0qs=.51fa62bb-347e-4cbb-8107-23f6553aaba2@github.com>
Message-ID: <asZg57v8fS3LuCvq1J0k1UbF5PeYsbn8WRYRuStSyYw=.50941644-79ab-4e6a-83a7-a38ab86a8a6f@github.com>

On Tue, 28 Mar 2023 18:25:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a documentation bug for `CharacterCodingException` without any description to it as attached. A corresponding CSR is also drafted.
> 
> ![Screenshot 2023-03-28 at 11 19 00 AM](https://user-images.githubusercontent.com/3122603/228332508-74606c64-bce1-4135-a4cf-b0c76b902676.png)

This pull request has now been integrated.

Changeset: e3855d00
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3855d005408945ea00e3bc38a0f10bef45cd627
Stats:     15 lines in 2 files changed: 14 ins; 0 del; 1 mod

8304840: Dangling `CharacterCodingException` in a few javadoc descriptions

Reviewed-by: alanb, iris, rriggs, jpai

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

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

From bpb at openjdk.org  Wed Mar 29 16:39:18 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 16:39:18 GMT
Subject: RFR: 8202110: (fs) Default file system provider should load
 UnixNativeDispatcher lazily [v3]
In-Reply-To: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
Message-ID: <JvQtrVyCfGXDUXzlS2mKm5Nd64PNIgWLVwuf3GXoZd0=.fb582998-ab74-4f55-b9ee-6fc319d4d4e1@github.com>

> Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.

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

  8202110: Propagate cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13132/files
  - new: https://git.openjdk.org/jdk/pull/13132/files/267f9a69..6503dd8d

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

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

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

From bpb at openjdk.org  Wed Mar 29 16:39:22 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 16:39:22 GMT
Subject: RFR: 8202110: (fs) Default file system provider should load
 UnixNativeDispatcher lazily [v2]
In-Reply-To: <X1Nu0-zRmjlNkLy2UmDZ-kqSOfKobRn6s6_Xizr1zp8=.6ea1a0fc-0aa0-4a20-a43c-67707dbd75f3@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
 <xvQFxMMDpY4p16J3FtXyZrsVkYWEoQov9d6gJqkyrQY=.11afe4ec-617a-4363-9cd1-6a6e216b8957@github.com>
 <X1Nu0-zRmjlNkLy2UmDZ-kqSOfKobRn6s6_Xizr1zp8=.6ea1a0fc-0aa0-4a20-a43c-67707dbd75f3@github.com>
Message-ID: <rbcOfWPfbb_xa6FdLEOfOW48zvYnjjgsJ9duDvpqK9s=.dd5c8386-3448-4641-96ad-004c1efa0a9c@github.com>

On Wed, 29 Mar 2023 06:52:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8202110: Remove undocumented sun.nio.fs.chdirAllowed property and dependent code
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 81:
> 
>> 79:     // package-private
>> 80:     UnixFileSystem(UnixFileSystemProvider provider) {
>> 81:         String dir = SystemProps.initProperties().get("user.dir");
> 
> The original code used `StaticProperty.userDir()`.

Corrected in 6503dd8d50e6c3302cf9be3e70f43e84f0dcadb4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13132#discussion_r1152214323

From bpb at openjdk.org  Wed Mar 29 18:55:17 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 18:55:17 GMT
Subject: RFR: 8202110: (fs) Remove FileSystem support for resolving against
 a default directory (chdir configuration) [v3]
In-Reply-To: <JvQtrVyCfGXDUXzlS2mKm5Nd64PNIgWLVwuf3GXoZd0=.fb582998-ab74-4f55-b9ee-6fc319d4d4e1@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
 <JvQtrVyCfGXDUXzlS2mKm5Nd64PNIgWLVwuf3GXoZd0=.fb582998-ab74-4f55-b9ee-6fc319d4d4e1@github.com>
Message-ID: <vWP6ZUiSTjBtTSZXT4y4lE6RQQPg1Ey2Zk2Nkq30gq4=.d78a1792-0a92-48c2-8852-bee90c88b6b2@github.com>

On Wed, 29 Mar 2023 16:39:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8202110: Propagate cleanup

Early execution of `UnixNativeDispatcher` is avoided if support for resolving against a specified filesystem default directory is removed. This entails removing the undocumented property `sun.nio.fs.chdirAllowed` and setting the default directory to the value of the `user.dir` property.

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

PR Comment: https://git.openjdk.org/jdk/pull/13132#issuecomment-1489130824

From alanb at openjdk.org  Wed Mar 29 20:10:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 20:10:21 GMT
Subject: RFR: 8202110: (fs) Remove FileSystem support for resolving against
 a default directory (chdir configuration) [v3]
In-Reply-To: <JvQtrVyCfGXDUXzlS2mKm5Nd64PNIgWLVwuf3GXoZd0=.fb582998-ab74-4f55-b9ee-6fc319d4d4e1@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
 <JvQtrVyCfGXDUXzlS2mKm5Nd64PNIgWLVwuf3GXoZd0=.fb582998-ab74-4f55-b9ee-6fc319d4d4e1@github.com>
Message-ID: <9S_cGWNw9Y01Ag8YKIXG6Rr6zeDHQkskqQxcz8xjaj4=.9a82d9ea-eb14-427f-bece-67ca687d430a@github.com>

On Wed, 29 Mar 2023 16:39:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8202110: Propagate cleanup

Can UnixNativeDispatcher.getcwd be removed now?

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

PR Comment: https://git.openjdk.org/jdk/pull/13132#issuecomment-1489235668

From bpb at openjdk.org  Wed Mar 29 21:51:34 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 21:51:34 GMT
Subject: RFR: 8202110: (fs) Remove FileSystem support for resolving against
 a default directory (chdir configuration) [v4]
In-Reply-To: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
Message-ID: <gDXS2-L5C8KwGYTnm6jCpqWHyCpKTDGZ2LG0Wy6of7Y=.9ae3a061-2277-4d8f-a057-0bd1e16169c2@github.com>

> Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.

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

  8202110: Remove UnixNativeDispatcher::getcwd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13132/files
  - new: https://git.openjdk.org/jdk/pull/13132/files/6503dd8d..bc27bd67

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

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

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

From bpb at openjdk.org  Wed Mar 29 21:51:48 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 29 Mar 2023 21:51:48 GMT
Subject: RFR: 8202110: (fs) Remove FileSystem support for resolving against
 a default directory (chdir configuration) [v3]
In-Reply-To: <9S_cGWNw9Y01Ag8YKIXG6Rr6zeDHQkskqQxcz8xjaj4=.9a82d9ea-eb14-427f-bece-67ca687d430a@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
 <JvQtrVyCfGXDUXzlS2mKm5Nd64PNIgWLVwuf3GXoZd0=.fb582998-ab74-4f55-b9ee-6fc319d4d4e1@github.com>
 <9S_cGWNw9Y01Ag8YKIXG6Rr6zeDHQkskqQxcz8xjaj4=.9a82d9ea-eb14-427f-bece-67ca687d430a@github.com>
Message-ID: <j0AmFF2cclSVDmZ3EONzy-lUEOaKuKhgSUpL6hnkAfc=.ba258104-d2db-48bc-8c67-86b42286e873@github.com>

On Wed, 29 Mar 2023 20:07:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can UnixNativeDispatcher.getcwd be removed now?

Yes: removed in bc27bd673f682153c01dd7c1012a2d0779ef0e8b.

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

PR Comment: https://git.openjdk.org/jdk/pull/13132#issuecomment-1489350757

From psandoz at openjdk.org  Wed Mar 29 22:35:31 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 29 Mar 2023 22:35:31 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <jPVaoTe4yDNcopVbNL3HV2reRvc7C_wLR1uRdhfkgNM=.bd715322-36b4-4bfb-bee7-b25fa61fc73e@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <pYRtChaFVMs_cb5b2yJOF5-sgqyjzFpO3k_fkNH8Ezo=.3acc93cd-65b4-4722-8761-7f4e725fe68c@github.com>
 <jPVaoTe4yDNcopVbNL3HV2reRvc7C_wLR1uRdhfkgNM=.bd715322-36b4-4bfb-bee7-b25fa61fc73e@github.com>
Message-ID: <NfZ230hgiA7ucz6TasqN1epq9NxH9iCxA9Waxwiw0Kw=.534b3fec-a059-4abf-9a67-d1e356ff8378@github.com>

On Wed, 22 Mar 2023 14:07:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Back to @PaulSandoz  question - "how does the caller know what the structure contains?". The caller typically doesn't care too much about what the returned struct is. But it might care about which "values" can be captured. That said, the set of such interesting values, is not too surprising. As demonstrated in the example in the `Linker.capturedCallState` method, once the client knows the name (and "errno" is likely to be 90% case), everything else follows from there - as the layout can be used to obtain var handles for the required values.
>> 
>> But, perhaps, now that I write this, I realize that what @PaulSandoz might _really_ be asking is: how do I know that e.g. the returned struct will not contain e.g. nested structs, sequences, or other non-sense. So we might specify (in a normative way) that the returned layout is a struct layout, whose member layouts are one or more value layouts (possibly with some added padding layouts). The names of the value layouts reflect the names of the values that can be captured.
>> 
>> And _then_ we show an example of the layout we return for Windows/x64 (as that's more interesting).
>
> I've updated the specs as per how I interpret the comments above. Let me know your thoughts on this.

This is much clearer. Are the names of the struct members guaranteed to be symbols that can be found up via the linker's default lookup? i.e. a small set of important global variables.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152550849

From mcimadamore at openjdk.org  Wed Mar 29 23:52:04 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 29 Mar 2023 23:52:04 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
Message-ID: <bvH6gsZpTzxMaJ7qeuFdDd7_HPR7B_z5tNVr3TiH9ic=.071272e4-b133-4d14-a9ca-c932ddb921ff@github.com>

On Wed, 29 Mar 2023 08:55:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup finality

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 410:

> 408:  * wrapping a native pointer. For instance, if such pointer points to a C struct, the client might prefer to resize the
> 409:  * segment unsafely, to match the size of the struct (so that out-of-bounds access will be detected by the API). If the
> 410:  * size is known statically, using an address layout with the correct target layout might be preferable.

Suggestion:

 * true size of the zero-length memory segment is known statically, using an address layout with the correct target layout might be preferable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152595828

From mcimadamore at openjdk.org  Wed Mar 29 23:58:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 29 Mar 2023 23:58:24 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <NfZ230hgiA7ucz6TasqN1epq9NxH9iCxA9Waxwiw0Kw=.534b3fec-a059-4abf-9a67-d1e356ff8378@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <pYRtChaFVMs_cb5b2yJOF5-sgqyjzFpO3k_fkNH8Ezo=.3acc93cd-65b4-4722-8761-7f4e725fe68c@github.com>
 <jPVaoTe4yDNcopVbNL3HV2reRvc7C_wLR1uRdhfkgNM=.bd715322-36b4-4bfb-bee7-b25fa61fc73e@github.com>
 <NfZ230hgiA7ucz6TasqN1epq9NxH9iCxA9Waxwiw0Kw=.534b3fec-a059-4abf-9a67-d1e356ff8378@github.com>
Message-ID: <Vflz_mf7Dn9Pw0djIiu5ZZMPPCKi8Kr1uys0tfxaSbc=.5b33a2a4-389a-4811-818d-1789760d3de1@github.com>

On Wed, 29 Mar 2023 22:32:20 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I've updated the specs as per how I interpret the comments above. Let me know your thoughts on this.
>
> This is much clearer. Are the names of the struct members guaranteed to be symbols that can be found up via the linker's default lookup? i.e. a small set of important global variables.

While they might be defined as global variable, I wouldn't read too much into this. Even `errno` is not really a global variable, but some thread local value that the native compiler knows about (e.g. setting the global variable doesn't really do much). Quoting from Linux man page:


errno  is  defined  by  the ISO C standard to be a modifiable lvalue of
       type int, and must not be explicitly declared; errno may  be  a  macro.
       errno  is  thread-local;  setting  it in one thread does not affect its
       value in any other thread.


This seems to imply that errno might even be something else. Given how the story goes for errno, I don't think we'd want to restrict the spec to state that these names should be discoverable via the lookup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152598834

From mcimadamore at openjdk.org  Thu Mar 30 00:05:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 30 Mar 2023 00:05:55 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
Message-ID: <QjLVFpYkPnC-7YF0iWtPRksI9-qmyvStS2Ylko6yQXo=.aec5c3ad-9c79-4ac7-b6f0-e226efdbda6e@github.com>

On Wed, 29 Mar 2023 08:55:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup finality

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 396:

> 394:  *}
> 395:  *
> 396:  * Alternatively, if the size of the foreign segment is known statically, clients can associate a

Suggestion:

 * Alternatively, if the true size of the zero-length memory segment is known statically, clients can associate a

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152602321

From alanb at openjdk.org  Thu Mar 30 06:46:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 06:46:18 GMT
Subject: RFR: 8202110: (fs) Remove FileSystem support for resolving against
 a default directory (chdir configuration) [v4]
In-Reply-To: <gDXS2-L5C8KwGYTnm6jCpqWHyCpKTDGZ2LG0Wy6of7Y=.9ae3a061-2277-4d8f-a057-0bd1e16169c2@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
 <gDXS2-L5C8KwGYTnm6jCpqWHyCpKTDGZ2LG0Wy6of7Y=.9ae3a061-2277-4d8f-a057-0bd1e16169c2@github.com>
Message-ID: <-rZm-wXYmiKKBNg991evfxYN-UYku1eSNpksItgqhhw=.994a79a3-283f-4b32-9315-d54c00c7be08@github.com>

On Wed, 29 Mar 2023 21:51:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8202110: Remove UnixNativeDispatcher::getcwd

A good cleanup.

src/java.base/windows/classes/sun/nio/fs/WindowsFileSystem.java line 47:

> 45:     // package-private
> 46:     WindowsFileSystem(WindowsFileSystemProvider provider)
> 47:     {

The "{" can be moved to the previous line now.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13132#pullrequestreview-1364424294
PR Review Comment: https://git.openjdk.org/jdk/pull/13132#discussion_r1152799631

From pminborg at openjdk.org  Thu Mar 30 11:28:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 30 Mar 2023 11:28:25 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v16]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <p9ijGq25fS1pue7aXoUfsKjc76t-oHcssoKtXRE7c_s=.a5e3a921-ed1d-4d39-aebc-6a7b590b5bdc@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

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

 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/c787a282..928ad35e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=14-15

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

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

From bpb at openjdk.org  Thu Mar 30 15:19:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 30 Mar 2023 15:19:40 GMT
Subject: RFR: 8202110: (fs) Remove FileSystem support for resolving against
 a default directory (chdir configuration) [v5]
In-Reply-To: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
Message-ID: <B9xyLtdqGEoKInR_5GXJCQr0yav1lfpbg0pl4NJ7Qo4=.4ae05b16-b523-4130-9cd3-7e98414953bf@github.com>

> Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.

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

  8202110: Align bracket of WindowsFileSystem constructor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13132/files
  - new: https://git.openjdk.org/jdk/pull/13132/files/bc27bd67..66788f5d

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

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

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

From bpb at openjdk.org  Thu Mar 30 15:19:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 30 Mar 2023 15:19:45 GMT
Subject: RFR: 8202110: (fs) Remove FileSystem support for resolving against
 a default directory (chdir configuration) [v4]
In-Reply-To: <-rZm-wXYmiKKBNg991evfxYN-UYku1eSNpksItgqhhw=.994a79a3-283f-4b32-9315-d54c00c7be08@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
 <gDXS2-L5C8KwGYTnm6jCpqWHyCpKTDGZ2LG0Wy6of7Y=.9ae3a061-2277-4d8f-a057-0bd1e16169c2@github.com>
 <-rZm-wXYmiKKBNg991evfxYN-UYku1eSNpksItgqhhw=.994a79a3-283f-4b32-9315-d54c00c7be08@github.com>
Message-ID: <HL8UsJJYKZkdfJ0vfRqG3Ih5o3sFXpJbYg_y8vzcp3M=.87c1080f-1a3b-4777-a627-409b1ef52f9b@github.com>

On Thu, 30 Mar 2023 06:41:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8202110: Remove UnixNativeDispatcher::getcwd
>
> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystem.java line 47:
> 
>> 45:     // package-private
>> 46:     WindowsFileSystem(WindowsFileSystemProvider provider)
>> 47:     {
> 
> The "{" can be moved to the previous line now.

Cleaned up in 66788f5d74ff9088b08159ff3ccd4b49cdaf6bbb.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13132#discussion_r1153419299

From alanb at openjdk.org  Thu Mar 30 15:37:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 15:37:21 GMT
Subject: RFR: 8202110: (fs) Remove FileSystem support for resolving against
 a default directory (chdir configuration) [v5]
In-Reply-To: <B9xyLtdqGEoKInR_5GXJCQr0yav1lfpbg0pl4NJ7Qo4=.4ae05b16-b523-4130-9cd3-7e98414953bf@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
 <B9xyLtdqGEoKInR_5GXJCQr0yav1lfpbg0pl4NJ7Qo4=.4ae05b16-b523-4130-9cd3-7e98414953bf@github.com>
Message-ID: <dvAI9k8IYtYOxHV2TTZFRx6ybaM4vigZyt9MXYQX6CY=.f84acc4f-1b7c-42b2-8fae-a37ae9633aec@github.com>

On Thu, 30 Mar 2023 15:19:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8202110: Align bracket of WindowsFileSystem constructor

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13132#pullrequestreview-1365407129

From bpb at openjdk.org  Thu Mar 30 16:48:17 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 30 Mar 2023 16:48:17 GMT
Subject: Integrated: 8202110: (fs) Remove FileSystem support for resolving
 against a default directory (chdir configuration)
In-Reply-To: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
References: <5oiN2L_4Epw_KePlEYYZm7qSG60RUSzG4HcJeBJE40U=.a40ea209-1529-41d6-94bb-f3cf2ba8c6c2@github.com>
Message-ID: <XvhaAC17-b1IxRHr2S0nsympgtqRRvnaOuraV7gPkx4=.06d40cbf-5c00-4e4d-99f3-c635cfa3de07@github.com>

On Tue, 21 Mar 2023 23:31:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Initialize `needToResolveAgainstDefaultDirectory` instance variable lazily thereby deferring early use of `UnixNativeDispatcher` and hopefully loading `libnio`.

This pull request has now been integrated.

Changeset: 05cc02b2
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05cc02b2438d9fffb1b074d9d68948265a36b6f0
Stats:     108 lines in 15 files changed: 4 ins; 64 del; 40 mod

8202110: (fs) Remove FileSystem support for resolving against a default directory (chdir configuration)

Reviewed-by: alanb

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

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

From jjg at openjdk.org  Thu Mar 30 17:31:12 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 17:31:12 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
Message-ID: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>

Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.

This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.

While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.

It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]

[here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
[disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

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

Commit messages:
 - JDK-8305206: Add @spec tags in java.base/java.* (part 1)

Changes: https://git.openjdk.org/jdk/pull/13248/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305206
  Stats: 281 lines in 60 files changed: 267 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13248/head:pull/13248

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

From alanb at openjdk.org  Thu Mar 30 19:51:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 19:51:22 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

I skimmed through the changes and it looks quite good, much more workable than PR 11073.

Do you have a proposed ordering with other tags? I expected it would go with @see but I see several where @spec is before @author, and @see after @author. I know it doesn't really matter.

src/java.base/share/classes/java/lang/Thread.java line 1960:

> 1958:      *             thread.
> 1959:      *
> 1960:      * @spec jni/index.html Java Native Interface Specification

The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.

src/java.base/share/classes/java/nio/file/Files.java line 1724:

> 1722:      *
> 1723:      * @spec https://www.rfc-editor.org/info/rfc2045
> 1724:      *      RFC 2045: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies

Maybe this one can be put on two lines to avoid the wrapping when looking at is side-by-side.

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

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1365814487
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153715180
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153716361

From jjg at openjdk.org  Thu Mar 30 20:33:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:33:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>
Message-ID: <ZXpGUrrQbi53QnGyYTMxbbQfepA4H-RzMTRDkmBAYAg=.41881291-c325-4291-808b-1369730c9869@github.com>

On Thu, 30 Mar 2023 19:42:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> src/java.base/share/classes/java/lang/Thread.java line 1960:
> 
>> 1958:      *             thread.
>> 1959:      *
>> 1960:      * @spec jni/index.html Java Native Interface Specification
> 
> The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.

Right now, the tag is added for any declaration whose comment contains a reference to an external spec (i.e. with `<a href-....>`. 

When we enable the "External Specifications" page, it will contain a link back to this page as part of the cross-reference info, which seems useful. That being said, if you feel strongly the tag should not be added here, I can remove it.

> src/java.base/share/classes/java/nio/file/Files.java line 1724:
> 
>> 1722:      *
>> 1723:      * @spec https://www.rfc-editor.org/info/rfc2045
>> 1724:      *      RFC 2045: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
> 
> Maybe this one can be put on two lines to avoid the wrapping when looking at is side-by-side.

Fixed. There was also a stutter-bug with a double "RFC 2045: RFC 2045:" which I have also fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153755656
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153756945

From jjg at openjdk.org  Thu Mar 30 20:45:10 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:45:10 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <AFuAduz4qqk1zQOOajsUEmtpy1XZ18P_95Av_6ZkKgs=.69b361cb-f738-4e62-a764-a21bec7df0f2@github.com>

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

> I skimmed through the changes and it looks quite good, much more workable than PR 11073.
> 
> Do you have a proposed ordering with other tags? I expected it would go with @see but I see several where @SPEC is before @author, and @see after @author. I know it doesn't really matter.

The initial assumption was "after the @param/@return/@throws group". Overall, as I said in the description for this PR, the block tags are not very consistent about ordering. I was thinking we might want to recommend an overall ordering, but I'm worried it would be too intrusive a change to apply generally.  In the description, I suggested an ordering based on the
order in `Docs.gmk` which defines the order in which tags appear in the generated output.

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1490920050

From jjg at openjdk.org  Thu Mar 30 20:45:08 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:45:08 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

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

  address review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13248/files
  - new: https://git.openjdk.org/jdk/pull/13248/files/3e1102a9..096a4188

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

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

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

From naoto at openjdk.org  Thu Mar 30 22:44:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Mar 2023 22:44:16 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <6a2ZYG8twjvIWSMNXjFdLra2lXGXoC3R9wyVFL8BAiY=.11396706-6da0-44fb-8e68-3965fd418edd@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Changes in i18n-related classes look good to me.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366032864

From darcy at openjdk.org  Fri Mar 31 04:35:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 Mar 2023 04:35:15 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <KrmUUZooBBZCX4WnmF1L1WpbI_lU2eXFldn_EMhoqYk=.717ec9fb-f542-48d5-b296-bab253be56bc@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Good to see these changes.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366237224

From alanb at openjdk.org  Fri Mar 31 10:26:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:26:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <nJ6I7j1VirPsWWSI1WgCK6FOVYxFpT163gKO8xzfbHE=.aa845440-9715-45ce-8587-e0112ae249ff@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366677936

From alanb at openjdk.org  Fri Mar 31 10:26:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:26:19 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <ZXpGUrrQbi53QnGyYTMxbbQfepA4H-RzMTRDkmBAYAg=.41881291-c325-4291-808b-1369730c9869@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>
 <ZXpGUrrQbi53QnGyYTMxbbQfepA4H-RzMTRDkmBAYAg=.41881291-c325-4291-808b-1369730c9869@github.com>
Message-ID: <EWW2GBqSWEKK01g2OWHM3TllOeAbIzNKQbQ_hdTWm0Q=.038c5f4a-b8ca-473d-8f31-3c4c67158432@github.com>

On Thu, 30 Mar 2023 20:28:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 1960:
>> 
>>> 1958:      *             thread.
>>> 1959:      *
>>> 1960:      * @spec jni/index.html Java Native Interface Specification
>> 
>> The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.
>
> Right now, the tag is added for any declaration whose comment contains a reference to an external spec (i.e. with `<a href-....>`. 
> 
> When we enable the "External Specifications" page, it will contain a link back to this page as part of the cross-reference info, which seems useful. That being said, if you feel strongly the tag should not be added here, I can remove it.

Leave it in for now and we can look at it again when the external spec page is in place. My comment is mostly that it will look a bit strange to link to this method because it's text in an implNote rather than spec.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154302925

From alanb at openjdk.org  Fri Mar 31 10:29:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:29:18 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: <AFuAduz4qqk1zQOOajsUEmtpy1XZ18P_95Av_6ZkKgs=.69b361cb-f738-4e62-a764-a21bec7df0f2@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <AFuAduz4qqk1zQOOajsUEmtpy1XZ18P_95Av_6ZkKgs=.69b361cb-f738-4e62-a764-a21bec7df0f2@github.com>
Message-ID: <ZGHuaYhpb5JLEXLMFrqw2WDNMATOUxwIjrpsurPb23Y=.d06e5ede-f7d4-4565-9e46-4ba049d79db2@github.com>

On Thu, 30 Mar 2023 20:38:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The initial assumption was "after the @param/@return/@throws group". Overall, as I said in the description for this PR, the block tags are not very consistent about ordering. I was thinking we might want to recommend an overall ordering, but I'm worried it would be too intrusive a change to apply generally. In the description, I suggested an ordering based on the order in `Docs.gmk` which defines the order in which tags appear in the generated output.

Okay, I think it's just a few of the usages that I sampled had author tags left over from early JDK releases and they end up between the spec and see tags. We can fix these things up at another time.

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1491696054

From lancea at openjdk.org  Fri Mar 31 10:36:17 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 Mar 2023 10:36:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Hi Jon,

This looks fine.  I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366691673

From dfuchs at openjdk.org  Fri Mar 31 10:44:17 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 31 Mar 2023 10:44:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <xhqVzVaj-GfS0YTdnG0h8FxEyfTmgaC045v38qGZc0o=.cf6e00c7-fb70-468e-a094-7a0cda52aaab@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

I had a look at the java.net part and it looks reasonable.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366700592

From lancea at openjdk.org  Fri Mar 31 10:48:13 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 Mar 2023 10:48:13 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>
Message-ID: <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>

On Fri, 31 Mar 2023 10:33:50 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi Jon,
> 
> This looks fine. I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?

Well, I must need coffee this morning as obviously JDBC is in the java.sql module, not java.base.... So scratch that comment ;-)

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1491723581

From mcimadamore at openjdk.org  Fri Mar 31 12:16:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 31 Mar 2023 12:16:22 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v16]
In-Reply-To: <p9ijGq25fS1pue7aXoUfsKjc76t-oHcssoKtXRE7c_s=.a5e3a921-ed1d-4d39-aebc-6a7b590b5bdc@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <p9ijGq25fS1pue7aXoUfsKjc76t-oHcssoKtXRE7c_s=.a5e3a921-ed1d-4d39-aebc-6a7b590b5bdc@github.com>
Message-ID: <ICq8Db2xl1tEwKoDV2uhyNp2h6mmRIpInc4_9_gZzKg=.02fa2afa-4c53-41bb-84fe-50a6677a3894@github.com>

On Thu, 30 Mar 2023 11:28:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

The class `jdk/internal/javac/PreviewFeature.java` needs to be updated. It is currently referring JEP 434:


public enum Feature {
        @JEP(number=433, title="Pattern Matching for switch", status="Fourth Preview")
        SWITCH_PATTERN_MATCHING(),
        @JEP(number=432, title="Record Patterns", status="Second Preview")
        RECORD_PATTERNS,
        @JEP(number=436, title="Virtual Threads", status="Second Preview")
        VIRTUAL_THREADS,
        @JEP(number=434, title="Foreign Function & Memory API", status="Second Preview")
        FOREIGN, // <-----------------------------------
        ...

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

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1491836954

From mullan at openjdk.org  Fri Mar 31 16:31:20 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 31 Mar 2023 16:31:20 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <xr0fgOmpPj6uUCvuSIiov-DKPYhTxPUEoFRwg-WSd7w=.1dd94a44-30f0-471d-a52a-7b16a431f882@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

I didn't see any changes to security APIs - are they coming in a follow-on issue?

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492236091

From iris at openjdk.org  Fri Mar 31 17:22:18 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 31 Mar 2023 17:22:18 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <MsIJ9F_LHrratAyjmUoPw1pEkxGYRo4L-tAmdkyWt8A=.8cb545c4-1daf-43c7-a4ef-5bc2feaf879d@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Marked as reviewed by iris (Reviewer).

src/java.base/share/classes/java/io/ObjectOutputStream.java line 165:

> 163:  * @see java.io.Serializable
> 164:  * @see java.io.Externalizable
> 165:  * @since       1.1

Just confirming... The changes to the java.io classes for the Serialization Spec now all point to the index rather than particular chapters/sections. I'm assuming that's intentional so that when the top-level Spec page appears, there is a single entry for that specification.

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

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367309978
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154716150

From mchung at openjdk.org  Fri Mar 31 17:25:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 31 Mar 2023 17:25:16 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <jmr06nDi3ImVdDXkR2CdZ2RiRqn0Nfk7lDiwR4VNXao=.87f529ea-5d89-4178-916b-f7d9e4bfa445@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

LGTM

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367320601

From jjg at openjdk.org  Fri Mar 31 18:29:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 18:29:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>
 <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>
Message-ID: <E6VI-_KYfAb3rvONO2NokBVCgNRU9Nkb5MRRpBiSXTI=.6228fc9b-37e5-495b-9971-adaacb8a502a@github.com>

On Fri, 31 Mar 2023 10:45:39 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > Hi Jon,
> > This looks fine. I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?
> 
> Well, I must need coffee this morning as obviously JDBC is in the java.sql module, not java.base.... So scratch that comment ;-)

The other modules will be done in due course.

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492417414

From jjg at openjdk.org  Fri Mar 31 18:29:20 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 18:29:20 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <MsIJ9F_LHrratAyjmUoPw1pEkxGYRo4L-tAmdkyWt8A=.8cb545c4-1daf-43c7-a4ef-5bc2feaf879d@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <MsIJ9F_LHrratAyjmUoPw1pEkxGYRo4L-tAmdkyWt8A=.8cb545c4-1daf-43c7-a4ef-5bc2feaf879d@github.com>
Message-ID: <8CaBH8YGWfkV6NnZtXfTyDI90ZwzCWFF631EnE6sU0A=.7a4acefb-6b85-4f41-a642-e266ab24363f@github.com>

On Fri, 31 Mar 2023 17:14:01 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review feedback
>
> src/java.base/share/classes/java/io/ObjectOutputStream.java line 165:
> 
>> 163:  * @see java.io.Serializable
>> 164:  * @see java.io.Externalizable
>> 165:  * @since       1.1
> 
> Just confirming... The changes to the java.io classes for the Serialization Spec now all point to the index rather than particular chapters/sections. I'm assuming that's intentional so that when the top-level Spec page appears, there is a single entry for that specification.

The `@spec` tag should point to the root, but we should not remove more specific references to within the spec. I will review places where `@see` has been removed/replaced.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154774688

From bpb at openjdk.org  Fri Mar 31 21:23:30 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 31 Mar 2023 21:23:30 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v22]
In-Reply-To: <L7cbFqrlbFEhkPLzFwztKd-07PcbbyrFbdvuLQnFkNk=.6b6d670a-2665-478d-bdef-3b9008cb2432@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <L7cbFqrlbFEhkPLzFwztKd-07PcbbyrFbdvuLQnFkNk=.6b6d670a-2665-478d-bdef-3b9008cb2432@github.com>
Message-ID: <HzhoQY2tPK-_ofVg_eODWvwq7T_pSala1pCSLhehdfg=.cc1bf70e-dc1c-4559-9c38-c06631e9dc24@github.com>

On Tue, 21 Mar 2023 21:47:59 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dealing with FileChannel::write returning a value less than rndBytes.length

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/6711#pullrequestreview-1367630792

From duke at openjdk.org  Fri Mar 31 21:23:32 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 31 Mar 2023 21:23:32 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v19]
In-Reply-To: <ygISMhq8uaEeGaK_7m1g1hmfpmtudHyfRltdmWPCAF4=.741d5587-72f7-41b8-9a5d-a9cf5e105107@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <z_gEk-e1PRI4QAIUxJFgsUG6We97hTmjOf2EOAcWuDQ=.f7ba17ee-8842-403d-b726-9f2068301b71@github.com>
 <ygISMhq8uaEeGaK_7m1g1hmfpmtudHyfRltdmWPCAF4=.741d5587-72f7-41b8-9a5d-a9cf5e105107@github.com>
Message-ID: <cy7C451aENcohma7Ejm1Wb60vpmFahJ1eV5PfYl7uFg=.7dec180a-1623-4564-90a6-95a9fb837f8c@github.com>

On Fri, 17 Mar 2023 16:58:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - updated copyright
>>  - Implementing 8278268
>>    
>>    Signed-off-by: Markus Karg <markus at headcrashing.eu>
>
>> So can you please briefly **confirm** that I _shall not_ merge `TransferTo2` into `TransferTo` as _Lance_ proposed (hence `TransferTo2` will not be a _separate_ class anymore) but **instead** I _only shall_ abstract `testNullPointerException` and `testStreamContents` as _you_ proposed (hence keep `TransferTo2` as a _separate_ class)? Thanks.
> 
> That is fine for now. It will be possible to revisit merging at a later time if it appears reasonable.
> 
>> > ...I think the two tests `*_2GB*` should remain separate as they likely each have a sufficiently long run time.
>> 
>> I confirm that we had intentionally kept these two tests in separate classes due to the long run time of each, so I agree to keep them _as separate_ classes, but I will reduce _duplicate_ code.
> 
> Sounds good.
> 
>> So can you please briefly **confirm** that I am correct with this objection and the 2GB files _should not_ be renamed?
> 
> That is fine.

@bplb Your requested changes are done since one week. Kindly asking to proceed with this PR. Thanks. :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/6711#issuecomment-1492617384

From bpb at openjdk.org  Fri Mar 31 21:23:33 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 31 Mar 2023 21:23:33 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v19]
In-Reply-To: <ygISMhq8uaEeGaK_7m1g1hmfpmtudHyfRltdmWPCAF4=.741d5587-72f7-41b8-9a5d-a9cf5e105107@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <z_gEk-e1PRI4QAIUxJFgsUG6We97hTmjOf2EOAcWuDQ=.f7ba17ee-8842-403d-b726-9f2068301b71@github.com>
 <ygISMhq8uaEeGaK_7m1g1hmfpmtudHyfRltdmWPCAF4=.741d5587-72f7-41b8-9a5d-a9cf5e105107@github.com>
Message-ID: <DWKayHl1EACUnYguWiIgvF6NPSeyVeJTNlHhsChjLEw=.c2cbcea1-a53f-42d1-95cf-7204138f7a87@github.com>

On Fri, 17 Mar 2023 16:58:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - updated copyright
>>  - Implementing 8278268
>>    
>>    Signed-off-by: Markus Karg <markus at headcrashing.eu>
>
>> So can you please briefly **confirm** that I _shall not_ merge `TransferTo2` into `TransferTo` as _Lance_ proposed (hence `TransferTo2` will not be a _separate_ class anymore) but **instead** I _only shall_ abstract `testNullPointerException` and `testStreamContents` as _you_ proposed (hence keep `TransferTo2` as a _separate_ class)? Thanks.
> 
> That is fine for now. It will be possible to revisit merging at a later time if it appears reasonable.
> 
>> > ...I think the two tests `*_2GB*` should remain separate as they likely each have a sufficiently long run time.
>> 
>> I confirm that we had intentionally kept these two tests in separate classes due to the long run time of each, so I agree to keep them _as separate_ classes, but I will reduce _duplicate_ code.
> 
> Sounds good.
> 
>> So can you please briefly **confirm** that I am correct with this objection and the 2GB files _should not_ be renamed?
> 
> That is fine.

> @bplb Your requested changes are done since one week. Kindly asking to proceed with this PR. Thanks. :-)

Indeed I was intending to approve this afternoon. I read through it all and the tests look much better now.

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

PR Comment: https://git.openjdk.org/jdk/pull/6711#issuecomment-1492620222

From duke at openjdk.org  Fri Mar 31 21:33:29 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 31 Mar 2023 21:33:29 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v22]
In-Reply-To: <L7cbFqrlbFEhkPLzFwztKd-07PcbbyrFbdvuLQnFkNk=.6b6d670a-2665-478d-bdef-3b9008cb2432@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <L7cbFqrlbFEhkPLzFwztKd-07PcbbyrFbdvuLQnFkNk=.6b6d670a-2665-478d-bdef-3b9008cb2432@github.com>
Message-ID: <2xHPqwA-bI6pAf031Kb1FPY9xvqCEjQIv7eph_EQYZc=.67bd0f44-242e-4633-a33b-5cda5d329642@github.com>

On Tue, 21 Mar 2023 21:47:59 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dealing with FileChannel::write returning a value less than rndBytes.length

Thanks a lot for mentoring this PR, Brian. :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/6711#issuecomment-1492632259

From jjg at openjdk.org  Fri Mar 31 22:07:26 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 22:07:26 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v3]
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <AzM9yIt0ic_LC_pI2Qi4oVMumARhGVjLVNoAM53uT28=.2d9a6869-38b8-421a-99c8-7e2155e8701b@github.com>

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

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

  revert removing @see tags where the URL was not the same as the @spec URL

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13248/files
  - new: https://git.openjdk.org/jdk/pull/13248/files/096a4188..7f64cc32

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

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

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

From jjg at openjdk.org  Fri Mar 31 22:18:15 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 22:18:15 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <xr0fgOmpPj6uUCvuSIiov-DKPYhTxPUEoFRwg-WSd7w=.1dd94a44-30f0-471d-a52a-7b16a431f882@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <xr0fgOmpPj6uUCvuSIiov-DKPYhTxPUEoFRwg-WSd7w=.1dd94a44-30f0-471d-a52a-7b16a431f882@github.com>
Message-ID: <is-v-fguWbSiEU4xVmQNC5S8HrjugCcUZ-LCgO9baSk=.89991275-b806-48d1-8920-08afabb59cab@github.com>

On Fri, 31 Mar 2023 16:28:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I didn't see any changes to security APIs - are they coming in a follow-on issue?

Yes, this is _Add `@spec` tags in java.base/java.* (part 1)_
The rest of `java.base` will be in part 2.

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492670942

From Alan.Bateman at oracle.com  Tue Mar 14 08:03:28 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Mar 2023 08:03:28 -0000
Subject: String encoding to ByteBuffer
In-Reply-To: <82795151-C155-4D44-B875-E27F7E81E70C@oracle.com>
References: <1127337400.2205617.1677454797231@email.ionos.com>
 <82795151-C155-4D44-B875-E27F7E81E70C@oracle.com>
Message-ID: <557b48d8-1690-dea3-e9a3-97e96cce9ef4@oracle.com>

On 13/03/2023 23:16, Brian Burkhalter wrote:
> Redirecting to nio-dev which is the more appropriate forum for this topic.
>
There have been a couple of explorations into this, one was Richard 
Warburton's prototype [1]. There are a couple of follow-up threads about 
this on core-libs-dev and nio-dev, including explorations into additions 
to CharsetEncoder.

-Alan

[1] 
https://mail.openjdk.org/pipermail/core-libs-dev/2014-September/028837.html