From alanb at openjdk.org  Tue Nov  1 07:51:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 07:51:20 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v2]
In-Reply-To: <N91fGkw-UVl67RR9ZeEM3p7KrSEmXWcLh-av0RABaw8=.aa941c91-471f-4e59-9646-ce2a0b9a0c56@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <N91fGkw-UVl67RR9ZeEM3p7KrSEmXWcLh-av0RABaw8=.aa941c91-471f-4e59-9646-ce2a0b9a0c56@github.com>
Message-ID: <LbmsvjBGIZ9iNWDYjJiIwhZr6e1jVuSU9r0R5AaNqt8=.a5671c25-194c-4a3d-bf8e-17e98997c0c9@github.com>

On Tue, 25 Oct 2022 23:36:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On macOS, ensure that the components of the `Path` returned by `UnixPath::toRealPath` have the case retained by the file system as opposed to that of the representation present in the `UnixPath` instance.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge
>  - 8295753: Use UnixDirectoryStream; compare UnixFileKeys; add SecurityManager
>  - 8295753: (fs) UnixPath::toRealPath does not return correct case when links not followed

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

> 869: 
> 870:         // Return if the file system is not both case insensitive and retentive
> 871:         if (!fs.isCaseInsensitiveAndRetentive())

I think we need to find a better name for this method. Maybe "Preserving" rather than "Retentive" would work better here.

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

> 880:         // entry in the same directory which has an equal key
> 881:         for (int i = 0; i < result.getNameCount(); i++ ) {
> 882:             UnixPath elt = result.getName(i);

Minor nit but the the naming above is "element", it switches to "elt" here.

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

> 904:             // Check readbility of path thus far
> 905:             if (sm != null)
> 906:                 sm.checkRead(path.getPathForPermissionCheck());

I don't think this permission check is needed here. The "checkRead" at line 816 does the require check for the method.

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

> 912:                     attributes = UnixFileAttributes.get(toUnixPath(p), false);
> 913:                 } catch (UnixException x) {
> 914:                     x.rethrowAsIOException(this);

This is problematic as it means that toRealPath can fail trying to access a file that is not in the path. Also given that it is only looking for one file then it might be simpler to just handle in the loop rather than as a filter.

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

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

From mkartashev at openjdk.org  Tue Nov  1 11:00:38 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 1 Nov 2022 11:00:38 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v8]
In-Reply-To: <8WHg8QPgBC2O2sYDXXHnL3Y2nS20dlzyUxRjr5r4Ctg=.2b07af8d-cc32-4f4f-bc6b-e043e6df66f7@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <h_gfCViVs9KuMeIhDCNzGD4N8wE57ArJM-T2EGyYzP4=.3c87b1de-2e58-44b5-85cb-3e66dd9dca22@github.com>
 <ay4oDKjwTh1VmbQlijzYRv7z3H0XSZB3TfiatnBZkDY=.42148f56-389b-4526-bf35-fc1789d57e73@github.com>
 <Nf4JhsYqnMvgXYoKLnBeeuRNdTlh_q8INM-rpyKxnQM=.71f14f0b-dfb9-4b9b-ad04-d69e5d2d5b4f@github.com>
 <8WHg8QPgBC2O2sYDXXHnL3Y2nS20dlzyUxRjr5r4Ctg=.2b07af8d-cc32-4f4f-bc6b-e043e6df66f7@github.com>
Message-ID: <FQNZShhp0bmnGswXBPaZ8rYHSAgi1W3K5b6rVZWWlZM=.f1864e4f-5fd1-46c1-a5fc-67834fb19411@github.com>

On Wed, 19 Oct 2022 16:56:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> There was such a suggestion (not sure about "off by default", though). I guess this should go through CSR review, in which case I'm going to need some guidance.
>
> If you file a CSR then I can help with editing.

Filed https://bugs.openjdk.org/browse/JDK-8296164
@bplb Could you please take a look and edit parts that need it?

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

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

From mkartashev at openjdk.org  Tue Nov  1 11:09:18 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 1 Nov 2022 11:09:18 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v7]
In-Reply-To: <kSqOIV5i6DIEJyLukIWXL3WXkFE_VM4rmxPjaUhicpQ=.3409ca50-aeff-4a43-9032-2e1dd737b73f@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <lavTvebuaR_OHPaksbIwZiTBOg1z1gkno6WRt5mkcKA=.d64e38a6-f16b-491b-aa2d-1c8331b13e19@github.com>
 <kSqOIV5i6DIEJyLukIWXL3WXkFE_VM4rmxPjaUhicpQ=.3409ca50-aeff-4a43-9032-2e1dd737b73f@github.com>
Message-ID: <lUZtwvQxQpyJgy8zOgTtz_LAdht5DkmagtQ5o3FcGr4=.cf15c203-d554-48e1-9632-ec9957cd2f6e@github.com>

On Sun, 9 Oct 2022 14:05:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dropped __unused attributes from used parameters
>
> It's a real shame that it requires use of a CFRunLoop and callbacks but if that is the only facility that it provides then I suppose we have to use it. I see the discussion about using a socketpair but I don't think that is sensible thing to do here. The socketpair that is used elsewhere is for wakeup only, similar to what we do in the Selector implementations. So I think we should move forward with the current approach but probably will need a few rounds of cleanup.

@AlanBateman Are there any outstanding issues that prevents this from being merged, apart from maybe the implementation of the [CSR](https://bugs.openjdk.org/browse/JDK-8296164)? I believe I addressed all the concerns raised in your comment from Sep, 11, but if more have been found since then, please do let me know.

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

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

From alanb at openjdk.org  Tue Nov  1 11:13:32 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 11:13:32 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v7]
In-Reply-To: <kSqOIV5i6DIEJyLukIWXL3WXkFE_VM4rmxPjaUhicpQ=.3409ca50-aeff-4a43-9032-2e1dd737b73f@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <lavTvebuaR_OHPaksbIwZiTBOg1z1gkno6WRt5mkcKA=.d64e38a6-f16b-491b-aa2d-1c8331b13e19@github.com>
 <kSqOIV5i6DIEJyLukIWXL3WXkFE_VM4rmxPjaUhicpQ=.3409ca50-aeff-4a43-9032-2e1dd737b73f@github.com>
Message-ID: <SBrfHnsvPJPo0aHjCJAgNtm5qQdKthzuNDOpSJDZwFk=.caa98470-5cdf-4e9e-828c-7ad5c5db1ff4@github.com>

On Sun, 9 Oct 2022 14:05:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dropped __unused attributes from used parameters
>
> It's a real shame that it requires use of a CFRunLoop and callbacks but if that is the only facility that it provides then I suppose we have to use it. I see the discussion about using a socketpair but I don't think that is sensible thing to do here. The socketpair that is used elsewhere is for wakeup only, similar to what we do in the Selector implementations. So I think we should move forward with the current approach but probably will need a few rounds of cleanup.

> @AlanBateman Are there any outstanding issues that prevents this from being merged, apart from maybe the implementation of the [CSR](https://bugs.openjdk.org/browse/JDK-8296164)? I believe I addressed all the concerns raised in your comment from Sep, 11, but if more have been found since then, please do let me know.

I've been tanked with other items. This PR is on my list to review. I would like to see this change in JDK 20.

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

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

From duke at openjdk.org  Tue Nov  1 11:49:43 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 1 Nov 2022 11:49:43 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v3]
In-Reply-To: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
Message-ID: <sZDepX9Ax4-sSn4lI5dJHtCbZBIlkjls2Hh9gJUG2Ok=.34027122-f837-4758-aef9-593b93c5a5f6@github.com>

> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
> 
> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.

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

  implemented feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10851/files
  - new: https://git.openjdk.org/jdk/pull/10851/files/795b073e..78b5bf66

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

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

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

From duke at openjdk.org  Tue Nov  1 11:49:43 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 1 Nov 2022 11:49:43 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v2]
In-Reply-To: <NI-H501EaGyu-RJQDitZ_fQyOVWvLLnWgy3xiPAssRM=.93bf6a3a-3839-413a-855e-811139889219@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <NI-H501EaGyu-RJQDitZ_fQyOVWvLLnWgy3xiPAssRM=.93bf6a3a-3839-413a-855e-811139889219@github.com>
Message-ID: <DP0ReJX8kHWAaMdG3-FeKTN9MOIHV8kkrfshs7EMsGQ=.faeb2825-d839-4485-a0b7-79d533618f48@github.com>

On Thu, 27 Oct 2022 16:28:29 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added loop to retry in event of interruption from other tests

Thanks for the comments, I've just pushed some changes based on them

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

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

From dfuchs at openjdk.org  Tue Nov  1 14:58:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 14:58:20 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v3]
In-Reply-To: <sZDepX9Ax4-sSn4lI5dJHtCbZBIlkjls2Hh9gJUG2Ok=.34027122-f837-4758-aef9-593b93c5a5f6@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <sZDepX9Ax4-sSn4lI5dJHtCbZBIlkjls2Hh9gJUG2Ok=.34027122-f837-4758-aef9-593b93c5a5f6@github.com>
Message-ID: <58LQO-tPDRU0dCm9GAEHi5GbQY_5ixb0yFIg3t7W3lQ=.bedd7f24-72a0-4b22-9889-267e76ca46ad@github.com>

On Tue, 1 Nov 2022 11:49:43 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implemented feedback

Changes requested by dfuchs (Reviewer).

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 58:

> 56:             dc.register(sel, SelectionKey.OP_READ);
> 57: 
> 58:             for (int i = 0; i < 3; i++) {

I suggest to define a `static int MAX_TRIES = 3;` and use that here:

for (int i = 0; i < MAX_TRIES; i++) {

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 73:

> 71:                     throw new RuntimeException("Unexpected wakeup");
> 72:                 }
> 73:             }

This should be:

                    if (ignoreStrayWakeup) {
                        if (i < MAX_TRIES - 1) continue;
                    }
                    // BindException will be thrown if another service is using 
                    // our expected refuser port, cannot run just exit.
                    DatagramChannel.open().bind(refuser).close();
                    throw new RuntimeException("Unexpected wakeup");
                } else {
                    break; 
                }

We don't want to silently finish and exit the loop if the last attempt failed. And we don't want to retry if n == 0.

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 74:

> 72:                 }
> 73:             }
> 74:             for (int i = 0; i < 3; i++) {

The loop should start after connecting.
It should be:

                /* Test 2: connected so ICMP port unreachable may be received */
                dc.connect(refuser);
                try {
                     for (int i = 0;  i < MAX_TRIES; i++) {
                         ...
                     }
                 } finally {
                      ...

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 97:

> 95:                         } catch (PortUnreachableException pue) {
> 96:                             // expected
> 97:                         }

This should be:

                            throw new RuntimeException("PortUnreachableException not raised");
                        } catch (PortUnreachableException pue) {
                            // expected
                        }
                    }
                    break;

If we get `PortUnreachableException` we have what we expected and we can exit the loop. Same if n == 0;

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 103:

> 101:                 }
> 102:             }
> 103:             for (int i = 0; i < 3; i++) {

Use MAX_TRIES here too

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 106:

> 104:                 /* Test 3: not connected so ICMP port unreachable should not be received */
> 105:                 sendDatagram(dc, refuser);
> 106:                 int n = sel.select(2000);

Same here:

                    if (ignoreStrayWakeup) {
                        if (i < MAX_TRIES - 1) continue;
                    }

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 128:

> 126:         throws IOException
> 127:     {
> 128:         ByteBuffer bb = ByteBuffer.wrap("Greetings from SelectWhenRefused!".getBytes());

You could put the message in a static string constant, that would avoid repeating it.

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

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

From duke at openjdk.org  Tue Nov  1 16:20:32 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 1 Nov 2022 16:20:32 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
Message-ID: <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>

> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
> 
> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.

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

  addressing comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10851/files
  - new: https://git.openjdk.org/jdk/pull/10851/files/78b5bf66..bfa8ea57

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

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

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

From bpb at openjdk.org  Tue Nov  1 16:31:51 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Nov 2022 16:31:51 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v8]
In-Reply-To: <FQNZShhp0bmnGswXBPaZ8rYHSAgi1W3K5b6rVZWWlZM=.f1864e4f-5fd1-46c1-a5fc-67834fb19411@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <h_gfCViVs9KuMeIhDCNzGD4N8wE57ArJM-T2EGyYzP4=.3c87b1de-2e58-44b5-85cb-3e66dd9dca22@github.com>
 <ay4oDKjwTh1VmbQlijzYRv7z3H0XSZB3TfiatnBZkDY=.42148f56-389b-4526-bf35-fc1789d57e73@github.com>
 <Nf4JhsYqnMvgXYoKLnBeeuRNdTlh_q8INM-rpyKxnQM=.71f14f0b-dfb9-4b9b-ad04-d69e5d2d5b4f@github.com>
 <8WHg8QPgBC2O2sYDXXHnL3Y2nS20dlzyUxRjr5r4Ctg=.2b07af8d-cc32-4f4f-bc6b-e043e6df66f7@github.com>
 <FQNZShhp0bmnGswXBPaZ8rYHSAgi1W3K5b6rVZWWlZM=.f1864e4f-5fd1-46c1-a5fc-67834fb19411@github.com>
Message-ID: <ICUZ0-PGeM8QASztgXve5VGbs0ILVvClftlh9IRG_Zs=.5626c42e-4515-4def-b423-b29a57e4cca0@github.com>

On Tue, 1 Nov 2022 10:58:01 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> If you file a CSR then I can help with editing.
>
> Filed https://bugs.openjdk.org/browse/JDK-8296164
> @bplb Could you please take a look and edit parts that need it?

@mkartashev I made some minor changes to the CSR. Was the property name previously agreed upon? I would tend to drop the `.use` from the end of it.

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

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

From dfuchs at openjdk.org  Tue Nov  1 16:51:18 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 16:51:18 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
Message-ID: <i5RwDDMTM3FQD3qGA5peMy_fTAtX2OQigsCWJlwUOJw=.3303187d-6db1-48e9-89c3-e15a93ebfef1@github.com>

On Tue, 1 Nov 2022 16:20:32 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing comments

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 39:

> 37: public class SelectWhenRefused {
> 38:     static int MAX_TRIES = 3;
> 39:     static String GREETINGS_MESSAGE = "Greetings from SelectWhenRefused!";

should be final

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

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

From dfuchs at openjdk.org  Tue Nov  1 16:57:44 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 16:57:44 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
Message-ID: <w2_SRSAYfLksDvdIaA8xGXDyrPYC1MGfmQIxchHuLmw=.67594ea9-2336-449b-a812-af83e7d3bad7@github.com>

On Tue, 1 Nov 2022 16:20:32 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing comments

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 76:

> 74:                 } else {
> 75:                     break;
> 76:                 }

nit: this is OK - but in fact the else isn't even needed. My bad. We could just break after the if, whether we entered it or not, because if we reach here it means we have found what we expected: all other paths result in continue or throw. So this could just be:

if (n > 0) { ...
}
break;

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

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

From alanb at openjdk.org  Tue Nov  1 18:13:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 18:13:23 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
Message-ID: <h4sb1nfT9PnO0f6rFPVl_oazAHhOeh0oF8oDQpK0S0g=.8c4ac8bc-be93-4263-ad16-c1fdb70e2f6b@github.com>

On Tue, 1 Nov 2022 16:20:32 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing comments

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 136:

> 134:     }
> 135: 
> 136:     static boolean checkUnexpectedWakeup(DatagramChannel dc, Set<SelectionKey> selectedKeys) {

For the next iteration, would you mind dropping the selectedKeys parameter from this method. It doesn't make sense to be calling dc.receive in this loop. It would be a lot simpler to do the non-blocking dc.receive and print the sender/details when not null.

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

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

From dfuchs at openjdk.org  Tue Nov  1 18:27:27 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 18:27:27 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <h4sb1nfT9PnO0f6rFPVl_oazAHhOeh0oF8oDQpK0S0g=.8c4ac8bc-be93-4263-ad16-c1fdb70e2f6b@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
 <h4sb1nfT9PnO0f6rFPVl_oazAHhOeh0oF8oDQpK0S0g=.8c4ac8bc-be93-4263-ad16-c1fdb70e2f6b@github.com>
Message-ID: <KM8gZ2TCIWQLD7cZbOEbLTdUE6YIoUAZQtK5Ma35R-4=.42f85372-da45-4280-bc52-4835802d7fa0@github.com>

On Tue, 1 Nov 2022 18:11:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing comments
>
> test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 136:
> 
>> 134:     }
>> 135: 
>> 136:     static boolean checkUnexpectedWakeup(DatagramChannel dc, Set<SelectionKey> selectedKeys) {
> 
> For the next iteration, would you mind dropping the selectedKeys parameter from this method. It doesn't make sense to be calling dc.receive in this loop. It would be a lot simpler to do the non-blocking dc.receive and print the sender/details when not null.

I still believe it's interesting to see what key is selected and what's its state. Why is that a problem?

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

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

From alanb at openjdk.org  Tue Nov  1 18:39:33 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 18:39:33 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <KM8gZ2TCIWQLD7cZbOEbLTdUE6YIoUAZQtK5Ma35R-4=.42f85372-da45-4280-bc52-4835802d7fa0@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
 <h4sb1nfT9PnO0f6rFPVl_oazAHhOeh0oF8oDQpK0S0g=.8c4ac8bc-be93-4263-ad16-c1fdb70e2f6b@github.com>
 <KM8gZ2TCIWQLD7cZbOEbLTdUE6YIoUAZQtK5Ma35R-4=.42f85372-da45-4280-bc52-4835802d7fa0@github.com>
Message-ID: <7XC38QQIBijBtlkRjtbHpAP9RumEBJM8oKBr7YOjmxs=.723fed2e-902e-46da-ac16-936460feecfc@github.com>

On Tue, 1 Nov 2022 18:23:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 136:
>> 
>>> 134:     }
>>> 135: 
>>> 136:     static boolean checkUnexpectedWakeup(DatagramChannel dc, Set<SelectionKey> selectedKeys) {
>> 
>> For the next iteration, would you mind dropping the selectedKeys parameter from this method. It doesn't make sense to be calling dc.receive in this loop. It would be a lot simpler to do the non-blocking dc.receive and print the sender/details when not null.
>
> I still believe it's interesting to see what key is selected and what's its state. Why is that a problem?

It make no sense because it puts the dc.receive into the loop that is examining the keys. If you really want to look at the state of the key then capture the result of the register method so you can print it out after the selection operation.

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

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

From dfuchs at openjdk.org  Tue Nov  1 18:49:00 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 18:49:00 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <7XC38QQIBijBtlkRjtbHpAP9RumEBJM8oKBr7YOjmxs=.723fed2e-902e-46da-ac16-936460feecfc@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
 <h4sb1nfT9PnO0f6rFPVl_oazAHhOeh0oF8oDQpK0S0g=.8c4ac8bc-be93-4263-ad16-c1fdb70e2f6b@github.com>
 <KM8gZ2TCIWQLD7cZbOEbLTdUE6YIoUAZQtK5Ma35R-4=.42f85372-da45-4280-bc52-4835802d7fa0@github.com>
 <7XC38QQIBijBtlkRjtbHpAP9RumEBJM8oKBr7YOjmxs=.723fed2e-902e-46da-ac16-936460feecfc@github.com>
Message-ID: <hhlJEcPaHiLsg0ayZMOUPH3mZ-tMfTxTm4wXwKfW4AU=.57938074-5f5d-4985-9a57-96101701a3cd@github.com>

On Tue, 1 Nov 2022 18:37:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I still believe it's interesting to see what key is selected and what's its state. Why is that a problem?
>
> It make no sense because it puts the dc.receive into the loop that is examining the keys. If you really want to look at the state of the key then capture the result of the register method so you can print it out after the selection operation.

I see. So you advise to pass the single key we obtained when registering the channel, to the method, rather than the selected key set. That's OK with me too.

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

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

From alanb at openjdk.org  Tue Nov  1 19:09:32 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Nov 2022 19:09:32 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <hhlJEcPaHiLsg0ayZMOUPH3mZ-tMfTxTm4wXwKfW4AU=.57938074-5f5d-4985-9a57-96101701a3cd@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
 <h4sb1nfT9PnO0f6rFPVl_oazAHhOeh0oF8oDQpK0S0g=.8c4ac8bc-be93-4263-ad16-c1fdb70e2f6b@github.com>
 <KM8gZ2TCIWQLD7cZbOEbLTdUE6YIoUAZQtK5Ma35R-4=.42f85372-da45-4280-bc52-4835802d7fa0@github.com>
 <7XC38QQIBijBtlkRjtbHpAP9RumEBJM8oKBr7YOjmxs=.723fed2e-902e-46da-ac16-936460feecfc@github.com>
 <hhlJEcPaHiLsg0ayZMOUPH3mZ-tMfTxTm4wXwKfW4AU=.57938074-5f5d-4985-9a57-96101701a3cd@github.com>
Message-ID: <ImIYHRPwGug1FtVw7C6Lb0_KLtC4xOJJGlue8sPNrnk=.5e3e9339-6fa0-4c29-9acf-4e31183b0d2c@github.com>

On Tue, 1 Nov 2022 18:45:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> It make no sense because it puts the dc.receive into the loop that is examining the keys. If you really want to look at the state of the key then capture the result of the register method so you can print it out after the selection operation.
>
> I see. So you advise to pass the single key we obtained when registering the channel, to the method, rather than the selected key set. That's OK with me too.

The method need only be passed one parameter, the DatagramChannel or the SelectionKey (key::channel will give you the channel). Right now it is confused because it wants to loop over all selected keys but it doesn't use the key's channel for the receive method. If I were changing this test then I think I would just pass it the DatagramChannel as the selection key is not really interesting. I think I would also change it to check if sa (the sender) is null so that it doesn't print a confusing message when no datagram has been received.

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

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

From bpb at openjdk.org  Tue Nov  1 21:38:38 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Nov 2022 21:38:38 GMT
Subject: Integrated: 8057113: (fs) Path should have a method to obtain the
 filename extension
In-Reply-To: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
Message-ID: <Mkf6884DbnUkkl1cryql9yfpaARYeaRpIpJLgNzLCLs=.070b0144-89a8-4187-8ebb-d7eddb237e30@github.com>

On Thu, 31 Mar 2022 20:28:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319).

This pull request has now been integrated.

Changeset: 50d91a31
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50d91a31d495adf8e189d0188918f4ff22f93876
Stats:     145 lines in 2 files changed: 143 ins; 0 del; 2 mod

8057113: (fs) Path should have a method to obtain the filename extension

Reviewed-by: rriggs, lancea, mr, alanb

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

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

From jpai at openjdk.org  Wed Nov  2 05:43:31 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Nov 2022 05:43:31 GMT
Subject: RFR: 8289689: (fs) Re-examine the need for normalization to
 Unicode Normalization Format D (macOS) [v3]
In-Reply-To: <c0Lw0xgsSR1WJnkQb-Hrq4IYHbLtYVIafz_x5rsP_yY=.61d2b8bb-ff05-4d8e-b313-2a8298b54b93@github.com>
References: <Ar03BhBgs-iCkZYFNcr90tIsPoj94X464OkDZ-twzaw=.1573f75c-b017-4fd6-9eaf-34668a77781a@github.com>
 <c0Lw0xgsSR1WJnkQb-Hrq4IYHbLtYVIafz_x5rsP_yY=.61d2b8bb-ff05-4d8e-b313-2a8298b54b93@github.com>
Message-ID: <rPcKJyT5usRt1W5NPdwqX4cw8ePMiMqc1MfqkBCnloQ=.cb361a1d-dacf-47b3-9746-81076bb6e2a7@github.com>

On Mon, 31 Oct 2022 16:37:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On macOS, perform file name normalization if and only if a specific system property is set.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289689: Remove unneeded check of ENABLE_FILE_NAME_ENCODING in test

Marked as reviewed by jpai (Reviewer).

Thank you for that change in the test, Brian. The test looks fine to me. The source change looks fine too, but I don't have enough knowledge of it.

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

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

From jpai at openjdk.org  Wed Nov  2 05:48:05 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Nov 2022 05:48:05 GMT
Subject: RFR: 8289689: (fs) Re-examine the need for normalization to
 Unicode Normalization Format D (macOS) [v3]
In-Reply-To: <c0Lw0xgsSR1WJnkQb-Hrq4IYHbLtYVIafz_x5rsP_yY=.61d2b8bb-ff05-4d8e-b313-2a8298b54b93@github.com>
References: <Ar03BhBgs-iCkZYFNcr90tIsPoj94X464OkDZ-twzaw=.1573f75c-b017-4fd6-9eaf-34668a77781a@github.com>
 <c0Lw0xgsSR1WJnkQb-Hrq4IYHbLtYVIafz_x5rsP_yY=.61d2b8bb-ff05-4d8e-b313-2a8298b54b93@github.com>
Message-ID: <qIfw511xGdZDqxpXzZy4zOqo6yNDvbOPGYE4UJ5QICY=.53db9a4f-7364-4020-a22f-4c610d565697@github.com>

On Mon, 31 Oct 2022 16:37:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On macOS, perform file name normalization if and only if a specific system property is set.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289689: Remove unneeded check of ENABLE_FILE_NAME_ENCODING in test

On a related note, have we tested this change on a macos version < 10.13 just to be sure that the command line flag does indeed allow to revert back to old behaviour on those setups?

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

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

From jpai at openjdk.org  Wed Nov  2 05:51:03 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Nov 2022 05:51:03 GMT
Subject: RFR: 8289689: (fs) Re-examine the need for normalization to
 Unicode Normalization Format D (macOS) [v3]
In-Reply-To: <c0Lw0xgsSR1WJnkQb-Hrq4IYHbLtYVIafz_x5rsP_yY=.61d2b8bb-ff05-4d8e-b313-2a8298b54b93@github.com>
References: <Ar03BhBgs-iCkZYFNcr90tIsPoj94X464OkDZ-twzaw=.1573f75c-b017-4fd6-9eaf-34668a77781a@github.com>
 <c0Lw0xgsSR1WJnkQb-Hrq4IYHbLtYVIafz_x5rsP_yY=.61d2b8bb-ff05-4d8e-b313-2a8298b54b93@github.com>
Message-ID: <EgJAts6DcZJUsmTrCEV4MF8p47q2DXPXjctUQcvKZGI=.6fee19e8-2e26-4be7-bc14-57d8128fa7de@github.com>

On Mon, 31 Oct 2022 16:37:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On macOS, perform file name normalization if and only if a specific system property is set.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289689: Remove unneeded check of ENABLE_FILE_NAME_ENCODING in test

src/java.base/macosx/classes/sun/nio/fs/MacOSXFileSystem.java line 40:

> 38: 
> 39:     private static final String PROPERTY_ENABLE_FILE_NAME_ENCODING =
> 40:         "jdk.nio.path.useNormalizationFormD";

Do we document system properties like this one in some javadoc through the use of `@systemProperty` so that it shows up in the documentation? Or is it OK to just have this mentioned in the release notes?

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

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

From mkartashev at openjdk.org  Wed Nov  2 06:27:20 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 2 Nov 2022 06:27:20 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v8]
In-Reply-To: <ICUZ0-PGeM8QASztgXve5VGbs0ILVvClftlh9IRG_Zs=.5626c42e-4515-4def-b423-b29a57e4cca0@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <h_gfCViVs9KuMeIhDCNzGD4N8wE57ArJM-T2EGyYzP4=.3c87b1de-2e58-44b5-85cb-3e66dd9dca22@github.com>
 <ay4oDKjwTh1VmbQlijzYRv7z3H0XSZB3TfiatnBZkDY=.42148f56-389b-4526-bf35-fc1789d57e73@github.com>
 <Nf4JhsYqnMvgXYoKLnBeeuRNdTlh_q8INM-rpyKxnQM=.71f14f0b-dfb9-4b9b-ad04-d69e5d2d5b4f@github.com>
 <8WHg8QPgBC2O2sYDXXHnL3Y2nS20dlzyUxRjr5r4Ctg=.2b07af8d-cc32-4f4f-bc6b-e043e6df66f7@github.com>
 <FQNZShhp0bmnGswXBPaZ8rYHSAgi1W3K5b6rVZWWlZM=.f1864e4f-5fd1-46c1-a5fc-67834fb19411@github.com>
 <ICUZ0-PGeM8QASztgXve5VGbs0ILVvClftlh9IRG_Zs=.5626c42e-4515-4def-b423-b29a57e4cca0@github.com>
Message-ID: <fvqcSgHN-uY9Yn8QUGE0LeNM7XA2ZSMKA3EUZrcPSn0=.bb9502ad-022f-422a-9111-1f2595d7def9@github.com>

On Tue, 1 Nov 2022 16:29:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Was the property name previously agreed upon?

Nope. Please, rename as you see fit, I really have no preference nor do I have any experience in CSRs.

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

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

From dfuchs at openjdk.org  Wed Nov  2 11:53:31 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Nov 2022 11:53:31 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <ImIYHRPwGug1FtVw7C6Lb0_KLtC4xOJJGlue8sPNrnk=.5e3e9339-6fa0-4c29-9acf-4e31183b0d2c@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
 <h4sb1nfT9PnO0f6rFPVl_oazAHhOeh0oF8oDQpK0S0g=.8c4ac8bc-be93-4263-ad16-c1fdb70e2f6b@github.com>
 <KM8gZ2TCIWQLD7cZbOEbLTdUE6YIoUAZQtK5Ma35R-4=.42f85372-da45-4280-bc52-4835802d7fa0@github.com>
 <7XC38QQIBijBtlkRjtbHpAP9RumEBJM8oKBr7YOjmxs=.723fed2e-902e-46da-ac16-936460feecfc@github.com>
 <hhlJEcPaHiLsg0ayZMOUPH3mZ-tMfTxTm4wXwKfW4AU=.57938074-5f5d-4985-9a57-96101701a3cd@github.com>
 <ImIYHRPwGug1FtVw7C6Lb0_KLtC4xOJJGlue8sPNrnk=.5e3e9339-6fa0-4c29-9acf-4e31183b0d2c@github.com>
Message-ID: <abr3TbQg8XcRjc_vy_Un9Kzb4iCGvHtgeLFaB-JYAmQ=.af32a15a-85f4-4d21-a79d-4f3d4eb8224a@github.com>

On Tue, 1 Nov 2022 19:07:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I see. So you advise to pass the single key we obtained when registering the channel, to the method, rather than the selected key set. That's OK with me too.
>
> The method need only be passed one parameter, the DatagramChannel or the SelectionKey (key::channel will give you the channel). Right now it is confused because it wants to loop over all selected keys but it doesn't use the key's channel for the receive method. If I were changing this test then I think I would just pass it the DatagramChannel as the selection key is not really interesting. I think I would also change it to check if sa (the sender) is null so that it doesn't print a confusing message when no datagram has been received.

I had a suspicion that maybe the selector could be woken up if the key became invalid - even though since this is a datagram channel and we're not closing it, I don't see how it could happen. If the key is invalid, there would be nothing to read. In addition, `n` is not supposed to be `> 0`, therefore something unexpected is going on. It seems useful to double check our assumptions: n > 0 because the key is active for reading. I'd like to check that. Hence the idea that passing the key was important. And you only want to attempt reading if the key is active for reading. Otherwise we'd get some other kind of exception and we would still not be the wiser. Good point about calling `key::channel` though!

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

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

From duke at openjdk.org  Wed Nov  2 12:16:39 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 2 Nov 2022 12:16:39 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <abr3TbQg8XcRjc_vy_Un9Kzb4iCGvHtgeLFaB-JYAmQ=.af32a15a-85f4-4d21-a79d-4f3d4eb8224a@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
 <h4sb1nfT9PnO0f6rFPVl_oazAHhOeh0oF8oDQpK0S0g=.8c4ac8bc-be93-4263-ad16-c1fdb70e2f6b@github.com>
 <KM8gZ2TCIWQLD7cZbOEbLTdUE6YIoUAZQtK5Ma35R-4=.42f85372-da45-4280-bc52-4835802d7fa0@github.com>
 <7XC38QQIBijBtlkRjtbHpAP9RumEBJM8oKBr7YOjmxs=.723fed2e-902e-46da-ac16-936460feecfc@github.com>
 <hhlJEcPaHiLsg0ayZMOUPH3mZ-tMfTxTm4wXwKfW4AU=.57938074-5f5d-4985-9a57-96101701a3cd@github.com>
 <ImIYHRPwGug1FtVw7C6Lb0_KLtC4xOJJGlue8sPNrnk=.5e3e9339-6fa0-4c29-9acf-4e31183b0d2c@github.com>
 <abr3TbQg8XcRjc_vy_Un9Kzb4iCGvHtgeLFaB-JYAmQ=.af32a15a-85f4-4d21-a79d-4f3d4eb8224a@github.com>
Message-ID: <ImR6ef5O39LJ9EbmodkdFnzhm4lvgnGr9zoX7ZQgiXQ=.a508e264-857d-4537-8915-1380e59bad50@github.com>

On Wed, 2 Nov 2022 11:51:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The method need only be passed one parameter, the DatagramChannel or the SelectionKey (key::channel will give you the channel). Right now it is confused because it wants to loop over all selected keys but it doesn't use the key's channel for the receive method. If I were changing this test then I think I would just pass it the DatagramChannel as the selection key is not really interesting. I think I would also change it to check if sa (the sender) is null so that it doesn't print a confusing message when no datagram has been received.
>
> I had a suspicion that maybe the selector could be woken up if the key became invalid - even though since this is a datagram channel and we're not closing it, I don't see how it could happen. If the key is invalid, there would be nothing to read. In addition, `n` is not supposed to be `> 0`, therefore something unexpected is going on. It seems useful to double check our assumptions: n > 0 because the key is active for reading. I'd like to check that. Hence the idea that passing the key was important. And you only want to attempt reading if the key is active for reading. Otherwise we'd get some other kind of exception and we would still not be the wiser. Good point about calling `key::channel` though!

So remove all the key prints and just attempt dc.receive and try to show its result?

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

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

From dfuchs at openjdk.org  Wed Nov  2 12:23:03 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Nov 2022 12:23:03 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <ImR6ef5O39LJ9EbmodkdFnzhm4lvgnGr9zoX7ZQgiXQ=.a508e264-857d-4537-8915-1380e59bad50@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
 <h4sb1nfT9PnO0f6rFPVl_oazAHhOeh0oF8oDQpK0S0g=.8c4ac8bc-be93-4263-ad16-c1fdb70e2f6b@github.com>
 <KM8gZ2TCIWQLD7cZbOEbLTdUE6YIoUAZQtK5Ma35R-4=.42f85372-da45-4280-bc52-4835802d7fa0@github.com>
 <7XC38QQIBijBtlkRjtbHpAP9RumEBJM8oKBr7YOjmxs=.723fed2e-902e-46da-ac16-936460feecfc@github.com>
 <hhlJEcPaHiLsg0ayZMOUPH3mZ-tMfTxTm4wXwKfW4AU=.57938074-5f5d-4985-9a57-96101701a3cd@github.com>
 <ImIYHRPwGug1FtVw7C6Lb0_KLtC4xOJJGlue8sPNrnk=.5e3e9339-6fa0-4c29-9acf-4e31183b0d2c@github.com>
 <abr3TbQg8XcRjc_vy_Un9Kzb4iCGvHtgeLFaB-JYAmQ=.af32a15a-85f4-4d21-a79d-4f3d4eb8224a@github.com>
 <ImR6ef5O39LJ9EbmodkdFnzhm4lvgnGr9zoX7ZQgiXQ=.a508e264-857d-4537-8915-1380e59bad50@github.com>
Message-ID: <zT7K8jhUBVc1bEHqBhsQJxqp7SEYRNnggzyGsBdJHCw=.f73cda96-3ab0-4415-8bf7-132c4210a3da@github.com>

On Wed, 2 Nov 2022 12:12:41 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> I had a suspicion that maybe the selector could be woken up if the key became invalid - even though since this is a datagram channel and we're not closing it, I don't see how it could happen. If the key is invalid, there would be nothing to read. In addition, `n` is not supposed to be `> 0`, therefore something unexpected is going on. It seems useful to double check our assumptions: n > 0 because the key is active for reading. I'd like to check that. Hence the idea that passing the key was important. And you only want to attempt reading if the key is active for reading. Otherwise we'd get some other kind of exception and we would still not be the wiser. Good point about calling `key::channel` though!
>
> So remove all the key prints and just attempt dc.receive and try to show its result?

Please no. Pass the key (or selected key set) but not the dc, and obtain the dc by calling key::channel.

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

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

From duke at openjdk.org  Wed Nov  2 12:23:04 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 2 Nov 2022 12:23:04 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v4]
In-Reply-To: <zT7K8jhUBVc1bEHqBhsQJxqp7SEYRNnggzyGsBdJHCw=.f73cda96-3ab0-4415-8bf7-132c4210a3da@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <PZehDTG8jfiq2lVyHVBonldojaJONCbD6efkfo5gN2A=.78afeddb-7143-4bea-9f2b-1b3d54d873dc@github.com>
 <h4sb1nfT9PnO0f6rFPVl_oazAHhOeh0oF8oDQpK0S0g=.8c4ac8bc-be93-4263-ad16-c1fdb70e2f6b@github.com>
 <KM8gZ2TCIWQLD7cZbOEbLTdUE6YIoUAZQtK5Ma35R-4=.42f85372-da45-4280-bc52-4835802d7fa0@github.com>
 <7XC38QQIBijBtlkRjtbHpAP9RumEBJM8oKBr7YOjmxs=.723fed2e-902e-46da-ac16-936460feecfc@github.com>
 <hhlJEcPaHiLsg0ayZMOUPH3mZ-tMfTxTm4wXwKfW4AU=.57938074-5f5d-4985-9a57-96101701a3cd@github.com>
 <ImIYHRPwGug1FtVw7C6Lb0_KLtC4xOJJGlue8sPNrnk=.5e3e9339-6fa0-4c29-9acf-4e31183b0d2c@github.com>
 <abr3TbQg8XcRjc_vy_Un9Kzb4iCGvHtgeLFaB-JYAmQ=.af32a15a-85f4-4d21-a79d-4f3d4eb8224a@github.com>
 <ImR6ef5O39LJ9EbmodkdFnzhm4lvgnGr9zoX7ZQgiXQ=.a508e264-857d-4537-8915-1380e59bad50@github.com>
 <zT7K8jhUBVc1bEHqBhsQJxqp7SEYRNnggzyGsBdJHCw=.f73cda96-3ab0-4415-8bf7-132c4210a3da@github.com>
Message-ID: <O5IPE0AZYOJDjm2XeZhMACYFarNwg1Ht038J50iBPvc=.23c5430d-45ab-4847-bd31-19619f0ed428@github.com>

On Wed, 2 Nov 2022 12:17:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> So remove all the key prints and just attempt dc.receive and try to show its result?
>
> Please no. Pass the key (or selected key set) but not the dc, and obtain the dc by calling key::channel.

sorry your last comment hadn't loaded in for me on the github page for some reason, I hadn't been responding to it

Seeing it now though it sounds good

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

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

From duke at openjdk.org  Wed Nov  2 14:24:32 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 2 Nov 2022 14:24:32 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v5]
In-Reply-To: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
Message-ID: <6T_6wSQ0gx2HMUJNFoaUkok18pora6l_iI12SdKNhx4=.82875061-7e71-41cd-a3fc-3fae0c2c1e79@github.com>

> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
> 
> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.

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

  changed checkUnexpectedWakeup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10851/files
  - new: https://git.openjdk.org/jdk/pull/10851/files/bfa8ea57..3099caa8

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

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

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

From dfuchs at openjdk.org  Wed Nov  2 14:50:36 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Nov 2022 14:50:36 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v5]
In-Reply-To: <6T_6wSQ0gx2HMUJNFoaUkok18pora6l_iI12SdKNhx4=.82875061-7e71-41cd-a3fc-3fae0c2c1e79@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <6T_6wSQ0gx2HMUJNFoaUkok18pora6l_iI12SdKNhx4=.82875061-7e71-41cd-a3fc-3fae0c2c1e79@github.com>
Message-ID: <KjvEIrfYmXIEALwk6V6ufUtXrEKlYie6JtKuhac8yYU=.30a5dfdc-18a1-46f2-9936-924c97a25726@github.com>

On Wed, 2 Nov 2022 14:24:32 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed checkUnexpectedWakeup

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 97:

> 95:                             // our expected refuser port, cannot run just exit.
> 96:                             DatagramChannel.open().bind(refuser).close();
> 97:                             throw new RuntimeException("PortUnreachableException not raised");

maybe we could add `if (i < MAX_TRIES - 1) continue;` between line 96 and 97.

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 99:

> 97:                             throw new RuntimeException("PortUnreachableException not raised");
> 98:                         } catch (PortUnreachableException pue) {
> 99:                             // expected

We could log that:

    System.out.println("Got expected " + pue);

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 147:

> 145:                 ByteBuffer buf = ByteBuffer.allocate(100);
> 146:                 SocketAddress sa = datagramChannel.receive(buf);
> 147:                 String message = new String(buf.array());

You can't really use new String(buf.array()) here because you will read past the bytes that have been received. Also keep in mind that after receiving the position of the BB will be *at the end* of the message.

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 154:

> 152:                 if (message.contains(GREETINGS_MESSAGE)) {
> 153:                     return true;
> 154:                 }

That's wrong. Remember: we want to ignore stray wake-ups, and a stray wake-up is defined as receiving a datagram that doesn't come from our own test.

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

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

From bpb at openjdk.org  Wed Nov  2 16:23:27 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Nov 2022 16:23:27 GMT
Subject: RFR: 8289689: (fs) Re-examine the need for normalization to
 Unicode Normalization Format D (macOS) [v4]
In-Reply-To: <Ar03BhBgs-iCkZYFNcr90tIsPoj94X464OkDZ-twzaw=.1573f75c-b017-4fd6-9eaf-34668a77781a@github.com>
References: <Ar03BhBgs-iCkZYFNcr90tIsPoj94X464OkDZ-twzaw=.1573f75c-b017-4fd6-9eaf-34668a77781a@github.com>
Message-ID: <a7vZWGWGLX2j4BspIXuiMDALqzWaT5LvUuDWNF-7x5s=.21c745da-9749-488b-9972-cd421bbc1c9d@github.com>

> On macOS, perform file name normalization if and only if a specific system property is set.

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

  8289689: Clean up property handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10885/files
  - new: https://git.openjdk.org/jdk/pull/10885/files/b420d2ce..42855d60

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

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

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

From duke at openjdk.org  Wed Nov  2 17:01:25 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 2 Nov 2022 17:01:25 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v5]
In-Reply-To: <KjvEIrfYmXIEALwk6V6ufUtXrEKlYie6JtKuhac8yYU=.30a5dfdc-18a1-46f2-9936-924c97a25726@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <6T_6wSQ0gx2HMUJNFoaUkok18pora6l_iI12SdKNhx4=.82875061-7e71-41cd-a3fc-3fae0c2c1e79@github.com>
 <KjvEIrfYmXIEALwk6V6ufUtXrEKlYie6JtKuhac8yYU=.30a5dfdc-18a1-46f2-9936-924c97a25726@github.com>
Message-ID: <JnjZ5hDo0LTvX9U20Tsp0XPKQeKlQUtGi6jc9cxwUk4=.7a2ef863-59a4-4587-8e2e-2f98821d1393@github.com>

On Wed, 2 Nov 2022 14:39:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed checkUnexpectedWakeup
>
> test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 147:
> 
>> 145:                 ByteBuffer buf = ByteBuffer.allocate(100);
>> 146:                 SocketAddress sa = datagramChannel.receive(buf);
>> 147:                 String message = new String(buf.array());
> 
> You can't really use new String(buf.array()) here because you will read past the bytes that have been received. Also keep in mind that after receiving the position of the BB will be *at the end* of the message.

Adding `buf.flip()` between 146 and 147 should be enough to address this right?

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

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

From dfuchs at openjdk.org  Wed Nov  2 17:13:47 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Nov 2022 17:13:47 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v5]
In-Reply-To: <JnjZ5hDo0LTvX9U20Tsp0XPKQeKlQUtGi6jc9cxwUk4=.7a2ef863-59a4-4587-8e2e-2f98821d1393@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <6T_6wSQ0gx2HMUJNFoaUkok18pora6l_iI12SdKNhx4=.82875061-7e71-41cd-a3fc-3fae0c2c1e79@github.com>
 <KjvEIrfYmXIEALwk6V6ufUtXrEKlYie6JtKuhac8yYU=.30a5dfdc-18a1-46f2-9936-924c97a25726@github.com>
 <JnjZ5hDo0LTvX9U20Tsp0XPKQeKlQUtGi6jc9cxwUk4=.7a2ef863-59a4-4587-8e2e-2f98821d1393@github.com>
Message-ID: <gRqaJ-fbm-qxWo_XeAQkXE-NfKrwdbFDASP_zn1nghw=.105ada3a-a523-4e22-bf91-a005eb2b3540@github.com>

On Wed, 2 Nov 2022 16:57:41 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 147:
>> 
>>> 145:                 ByteBuffer buf = ByteBuffer.allocate(100);
>>> 146:                 SocketAddress sa = datagramChannel.receive(buf);
>>> 147:                 String message = new String(buf.array());
>> 
>> You can't really use new String(buf.array()) here because you will read past the bytes that have been received. Also keep in mind that after receiving the position of the BB will be *at the end* of the message.
>
> Adding `buf.flip()` between 146 and 147 should be enough to address this right?

No because buf.array() always return the same array of 100 bytes that the buffer wraps, regardless of the byte buffer position and limit.

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

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

From alanb at openjdk.org  Wed Nov  2 17:34:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Nov 2022 17:34:34 GMT
Subject: RFR: 8289689: (fs) Re-examine the need for normalization to
 Unicode Normalization Format D (macOS) [v4]
In-Reply-To: <a7vZWGWGLX2j4BspIXuiMDALqzWaT5LvUuDWNF-7x5s=.21c745da-9749-488b-9972-cd421bbc1c9d@github.com>
References: <Ar03BhBgs-iCkZYFNcr90tIsPoj94X464OkDZ-twzaw=.1573f75c-b017-4fd6-9eaf-34668a77781a@github.com>
 <a7vZWGWGLX2j4BspIXuiMDALqzWaT5LvUuDWNF-7x5s=.21c745da-9749-488b-9972-cd421bbc1c9d@github.com>
Message-ID: <nSm8hPgy-QtbsdKaqMLO8yl5Ydql6NqXk3RQpAgKhyc=.c6637364-8b53-43a1-9860-07f405d61783@github.com>

On Wed, 2 Nov 2022 16:23:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On macOS, perform file name normalization if and only if a specific system property is set.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289689: Clean up property handling

Marked as reviewed by alanb (Reviewer).

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

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

From bpb at openjdk.org  Thu Nov  3 01:10:12 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Nov 2022 01:10:12 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v2]
In-Reply-To: <LbmsvjBGIZ9iNWDYjJiIwhZr6e1jVuSU9r0R5AaNqt8=.a5671c25-194c-4a3d-bf8e-17e98997c0c9@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <N91fGkw-UVl67RR9ZeEM3p7KrSEmXWcLh-av0RABaw8=.aa941c91-471f-4e59-9646-ce2a0b9a0c56@github.com>
 <LbmsvjBGIZ9iNWDYjJiIwhZr6e1jVuSU9r0R5AaNqt8=.a5671c25-194c-4a3d-bf8e-17e98997c0c9@github.com>
Message-ID: <Ayg8U-kvcqtbDcswJOxjKm2UeQ91wjx_Xa1DXOidAnc=.2d80dbb3-6ea2-4d19-8898-cb6a47093fc7@github.com>

On Tue, 1 Nov 2022 07:47:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge
>>  - 8295753: Use UnixDirectoryStream; compare UnixFileKeys; add SecurityManager
>>  - 8295753: (fs) UnixPath::toRealPath does not return correct case when links not followed
>
> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 871:
> 
>> 869: 
>> 870:         // Return if the file system is not both case insensitive and retentive
>> 871:         if (!fs.isCaseInsensitiveAndRetentive())
> 
> I think we need to find a better name for this method. Maybe "Preserving" rather than "Retentive" would work better here.

Renamed in 49d18c6a39d9d70b7da91c5b4b3740ba3c890948.

> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 906:
> 
>> 904:             // Check readbility of path thus far
>> 905:             if (sm != null)
>> 906:                 sm.checkRead(path.getPathForPermissionCheck());
> 
> I don't think this permission check is needed here. The "checkRead" at line 816 does the require check for the method.

Removed in 49d18c6a39d9d70b7da91c5b4b3740ba3c890948.

> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 914:
> 
>> 912:                     attributes = UnixFileAttributes.get(toUnixPath(p), false);
>> 913:                 } catch (UnixException x) {
>> 914:                     x.rethrowAsIOException(this);
> 
> This is problematic as it means that toRealPath can fail trying to access a file that is not in the path. Also given that it is only looking for one file then it might be simpler to just handle in the loop rather than as a filter.

Addressed in 49d18c6a39d9d70b7da91c5b4b3740ba3c890948.

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

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

From bpb at openjdk.org  Thu Nov  3 01:10:05 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Nov 2022 01:10:05 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v3]
In-Reply-To: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
Message-ID: <hCh5fVLPnKiY8958b5b1GTN-FWlMnmY2r28BpRiRmDI=.61d32f06-1c5e-4781-a377-03fe2fa32de1@github.com>

> On macOS, ensure that the components of the `Path` returned by `UnixPath::toRealPath` have the case retained by the file system as opposed to that of the representation present in the `UnixPath` instance.

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

  8295753: Clean up UnixPath; rename retentive to preserving

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10843/files
  - new: https://git.openjdk.org/jdk/pull/10843/files/96c0257a..49d18c6a

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

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

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

From mik3hall at gmail.com  Thu Nov  3 01:46:18 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 2 Nov 2022 20:46:18 -0500
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v8]
In-Reply-To: <fvqcSgHN-uY9Yn8QUGE0LeNM7XA2ZSMKA3EUZrcPSn0=.bb9502ad-022f-422a-9111-1f2595d7def9@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <h_gfCViVs9KuMeIhDCNzGD4N8wE57ArJM-T2EGyYzP4=.3c87b1de-2e58-44b5-85cb-3e66dd9dca22@github.com>
 <ay4oDKjwTh1VmbQlijzYRv7z3H0XSZB3TfiatnBZkDY=.42148f56-389b-4526-bf35-fc1789d57e73@github.com>
 <Nf4JhsYqnMvgXYoKLnBeeuRNdTlh_q8INM-rpyKxnQM=.71f14f0b-dfb9-4b9b-ad04-d69e5d2d5b4f@github.com>
 <8WHg8QPgBC2O2sYDXXHnL3Y2nS20dlzyUxRjr5r4Ctg=.2b07af8d-cc32-4f4f-bc6b-e043e6df66f7@github.com>
 <FQNZShhp0bmnGswXBPaZ8rYHSAgi1W3K5b6rVZWWlZM=.f1864e4f-5fd1-46c1-a5fc-67834fb19411@github.com>
 <ICUZ0-PGeM8QASztgXve5VGbs0ILVvClftlh9IRG_Zs=.5626c42e-4515-4def-b423-b29a57e4cca0@github.com>
 <fvqcSgHN-uY9Yn8QUGE0LeNM7XA2ZSMKA3EUZrcPSn0=.bb9502ad-022f-422a-9111-1f2595d7def9@github.com>
Message-ID: <8A33C555-2C63-4063-976A-2298148DB392@gmail.com>



> On Nov 2, 2022, at 1:27 AM, Maxim Kartashev <mkartashev at openjdk.org> wrote:
> 
> On Tue, 1 Nov 2022 16:29:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
> 
>> Was the property name previously agreed upon?
> 
> Nope. Please, rename as you see fit, I really have no preference nor do I have any experience in CSRs.
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/10140

I had a thought for some code to try this on but seem to get a number of build errors now.

http://mikehall.pairserver.com/errors10140.txt <http://mikehall.pairserver.com/errors10140.txt>

Using the GitHub Desktop app to change to pr/10140



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221102/d5ad452a/attachment.htm>

From vkempik at openjdk.org  Thu Nov  3 11:26:11 2022
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Thu, 3 Nov 2022 11:26:11 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
Message-ID: <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>

On Wed, 19 Oct 2022 06:48:05 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> This is an implementation of `WatchService` based on File System Events API that is capable of generating events whenever a change occurs in an interesting directory or underneath it. Since the API naturally supports "recursive" watch, the `FILE_TREE` is supported by the watch service. 
>> 
>> Some things of note:
>> * There's one "service" thread per `WatchService` instance that is inactive unless changes occur in the watched directory. The changes are grouped by introducing a time delay between when they occurred and when they are reported, which is controlled by the sensitivity modifier of the watch service.
>> * Since FSEvents API reports directories only, the watch service keeps a snapshot (hierarchical if necessary) of the files in the directory being watched. The snapshot gets updated when an event in that directory or underneath it gets delivered. File changes are detected by comparing "last modified" time with a millisecond precision (`BasicFileAttributes.lastModifiedTime()`).
>> * There is a slight complication with the move of an entire directory hierarchy: FSEvents API only reports about the containing directory of that move and not about any of the directories actually moved. There's a separate test for that (`Move.java`).
>> * The code is careful not to do any I/O (such as reading the contents of a directory or attributes of a file) unless unavoidable. Any deviation from this line should be considered a bug (of, arguably, low priority).
>> * The native part consists mostly of API wrappers with one exception of the callback function invoked by the system to report the events that occurred. The sole task of the function is to convert from C strings to Java strings and pass the array of affected directories to Java code. This can be rewritten if desired to make the code more future-proof.
>> 
>> This commit leaves `PollingWatchService` unused. I'm not sure if I should/can do anything about it. Any advice is welcomed.
>> 
>> ### Testing
>> 
>> * Tested by running `test/jdk/java/nio/file` and `test/jdk/jdk/nio` on MacOS 10.15.7 (x64) and `test/jdk/java/nio/` plus `test/jdk/jdk/nio` on MacOS 12.5.1 (aarch64).
>> * Also verified that new tests pass on Linux and Windows.
>> * This code (albeit in a slightly modified form) has been in use at JetBrains for around half a year and a few bugs have been found and fixed during that time period.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected coding style

> _Mailing list message from [Michael Hall](mailto:mik3hall at gmail.com) on [nio-dev](mailto:nio-dev at mail.openjdk.org):_
> 
> I had a thought for some code to try this on but seem to get a number of build errors now.
> 
> http://mikehall.pairserver.com/errors10140.txt <http://mikehall.pairserver.com/errors10140.txt>
> 
> Using the GitHub Desktop app to change to pr/10140
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221102/d5ad452a/attachment.htm>

You are using xcode 14 with sdk for macos Ventura hence having issues. that's orthogonal to this PR.

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

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

From alanb at openjdk.org  Thu Nov  3 11:50:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Nov 2022 11:50:36 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v3]
In-Reply-To: <hCh5fVLPnKiY8958b5b1GTN-FWlMnmY2r28BpRiRmDI=.61d32f06-1c5e-4781-a377-03fe2fa32de1@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <hCh5fVLPnKiY8958b5b1GTN-FWlMnmY2r28BpRiRmDI=.61d32f06-1c5e-4781-a377-03fe2fa32de1@github.com>
Message-ID: <xGfec2fNpVnEGo3e8EiFcgEy6yntsL9sC4hcUA9Yhy8=.62921280-fe88-486a-bff1-11d12efd5dc5@github.com>

On Thu, 3 Nov 2022 01:10:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On macOS, ensure that the components of the `Path` returned by `UnixPath::toRealPath` have the case retained by the file system as opposed to that of the representation present in the `UnixPath` instance.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295753: Clean up UnixPath; rename retentive to preserving

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

> 812: 
> 813:     @Override
> 814:     @SuppressWarnings("removal")

I assume this can be removed.

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

> 874:         UnixPath path = fs.rootDirectory();
> 875: 
> 876:         SecurityManager sm = System.getSecurityManager();

I assume this can be removed too.

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

> 891:             UnixPath elementPath = path.resolve(element);
> 892: 
> 893:             // Derive element key

You might want to re-visit the comments at L890 and 893 and there is no deviation, instead it just gets the file key. The API allows is to be null but the Unix implementation is always non-null.

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

> 905:             DirectoryStream.Filter<Path> filter = (p) -> { return true; };
> 906:             try (DirectoryStream<Path> entries =
> 907:                 getFileSystem().provider().newDirectoryStream(path, filter)) {

I think the algorithm is correct, just need to fix the strange intend at 907.

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

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

From mik3hall at gmail.com  Thu Nov  3 11:54:48 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 3 Nov 2022 06:54:48 -0500
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
Message-ID: <573A74E9-1E98-4AAC-8014-D50C691A3771@gmail.com>



> On Nov 3, 2022, at 6:26 AM, Vladimir Kempik <vkempik at openjdk.org> wrote:
> 
> On Wed, 19 Oct 2022 06:48:05 GMT, Maxim Kartashev <mkartashev at openjdk.org <mailto:mkartashev at openjdk.org>> wrote:
> 
>>> This is an implementation of `WatchService` based on File System Events API that is capable of generating events whenever a change occurs in an interesting directory or underneath it. Since the API naturally supports "recursive" watch, the `FILE_TREE` is supported by the watch service. 
>>> 
>>> Some things of note:
>>> * There's one "service" thread per `WatchService` instance that is inactive unless changes occur in the watched directory. The changes are grouped by introducing a time delay between when they occurred and when they are reported, which is controlled by the sensitivity modifier of the watch service.
>>> * Since FSEvents API reports directories only, the watch service keeps a snapshot (hierarchical if necessary) of the files in the directory being watched. The snapshot gets updated when an event in that directory or underneath it gets delivered. File changes are detected by comparing "last modified" time with a millisecond precision (`BasicFileAttributes.lastModifiedTime()`).
>>> * There is a slight complication with the move of an entire directory hierarchy: FSEvents API only reports about the containing directory of that move and not about any of the directories actually moved. There's a separate test for that (`Move.java`).
>>> * The code is careful not to do any I/O (such as reading the contents of a directory or attributes of a file) unless unavoidable. Any deviation from this line should be considered a bug (of, arguably, low priority).
>>> * The native part consists mostly of API wrappers with one exception of the callback function invoked by the system to report the events that occurred. The sole task of the function is to convert from C strings to Java strings and pass the array of affected directories to Java code. This can be rewritten if desired to make the code more future-proof.
>>> 
>>> This commit leaves `PollingWatchService` unused. I'm not sure if I should/can do anything about it. Any advice is welcomed.
>>> 
>>> ### Testing
>>> 
>>> * Tested by running `test/jdk/java/nio/file` and `test/jdk/jdk/nio` on MacOS 10.15.7 (x64) and `test/jdk/java/nio/` plus `test/jdk/jdk/nio` on MacOS 12.5.1 (aarch64).
>>> * Also verified that new tests pass on Linux and Windows.
>>> * This code (albeit in a slightly modified form) has been in use at JetBrains for around half a year and a few bugs have been found and fixed during that time period.
>> 
>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  Corrected coding style
> 
>> _Mailing list message from [Michael Hall](mailto:mik3hall at gmail.com <mailto:mik3hall at gmail.com>) on [nio-dev](mailto:nio-dev at mail.openjdk.org <mailto:nio-dev at mail.openjdk.org>):_
>> 
>> I had a thought for some code to try this on but seem to get a number of build errors now.
>> 
>> http://mikehall.pairserver.com/errors10140.txt <http://mikehall.pairserver.com/errors10140.txt> <http://mikehall.pairserver.com/errors10140.txt <http://mikehall.pairserver.com/errors10140.txt>>
>> 
>> Using the GitHub Desktop app to change to pr/10140
>> 
>> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221102/d5ad452a/attachment.htm <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221102/d5ad452a/attachment.htm>>
> 
> You are using xcode 14 with sdk for macos Ventura hence having issues. that's orthogonal to this PR.
> 

I am not doing anything myself to use Xcode 14. I may of updated Xcode at some point to cause it. 
I am not saying the PR is responsible but it did build the last time I tried but didn?t this time.
I have been successfully building on a different branch.
Although, somewhat off-topic is anyone aware of what I need to do on OS/X to use a different version of Xcode for jdk builds?

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221103/d0c34c95/attachment.htm>

From prappo at openjdk.org  Thu Nov  3 12:12:42 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 3 Nov 2022 12:12:42 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v3]
In-Reply-To: <xGfec2fNpVnEGo3e8EiFcgEy6yntsL9sC4hcUA9Yhy8=.62921280-fe88-486a-bff1-11d12efd5dc5@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <hCh5fVLPnKiY8958b5b1GTN-FWlMnmY2r28BpRiRmDI=.61d32f06-1c5e-4781-a377-03fe2fa32de1@github.com>
 <xGfec2fNpVnEGo3e8EiFcgEy6yntsL9sC4hcUA9Yhy8=.62921280-fe88-486a-bff1-11d12efd5dc5@github.com>
Message-ID: <pRI8zhTQyLWk-NWc4ltAiCZgrtqGDGkaKhSPZxoDiHQ=.5473ef12-01eb-4121-b47e-6de4953df6d9@github.com>

On Thu, 3 Nov 2022 11:43:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think the algorithm is correct, just need to fix the strange intend at 907.

I assume you meant _indent(ation)_. If so, then I wonder what you'd consider as acceptable formatting here. Could `var` help not solve this problem by making 906-907 a one-liner instead? Or this would be too unusual for this class?

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

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

From prappo at openjdk.org  Thu Nov  3 12:22:03 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 3 Nov 2022 12:22:03 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v3]
In-Reply-To: <hCh5fVLPnKiY8958b5b1GTN-FWlMnmY2r28BpRiRmDI=.61d32f06-1c5e-4781-a377-03fe2fa32de1@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <hCh5fVLPnKiY8958b5b1GTN-FWlMnmY2r28BpRiRmDI=.61d32f06-1c5e-4781-a377-03fe2fa32de1@github.com>
Message-ID: <gjsus-b_Bi2MQbSGKeMpOeP-MZpBQ9hwMbmiGh6qjds=.3650e1aa-3996-4ef5-9a63-13910276f194@github.com>

On Thu, 3 Nov 2022 01:10:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On macOS, ensure that the components of the `Path` returned by `UnixPath::toRealPath` have the case retained by the file system as opposed to that of the representation present in the `UnixPath` instance.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295753: Clean up UnixPath; rename retentive to preserving

I note in passing that in Java code comments we call macOS all sorts of ways. Given the history of that OS naming, would there be any value in cleaning it up someday? Maybe we could be more consistent at least in java.base.

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

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

From duke at openjdk.org  Thu Nov  3 15:36:58 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Thu, 3 Nov 2022 15:36:58 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v6]
In-Reply-To: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
Message-ID: <hRas8QHjcVFW_wrw8D9EOE2kz3ILlJIWn-B0OrOztCw=.61170e37-c332-47fb-927b-d5965cd7192d@github.com>

> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
> 
> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.

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

  fixed buffer output

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10851/files
  - new: https://git.openjdk.org/jdk/pull/10851/files/3099caa8..43277609

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

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

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

From bpb at openjdk.org  Thu Nov  3 15:50:37 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Nov 2022 15:50:37 GMT
Subject: Integrated: 8289689: (fs) Re-examine the need for normalization to
 Unicode Normalization Format D (macOS)
In-Reply-To: <Ar03BhBgs-iCkZYFNcr90tIsPoj94X464OkDZ-twzaw=.1573f75c-b017-4fd6-9eaf-34668a77781a@github.com>
References: <Ar03BhBgs-iCkZYFNcr90tIsPoj94X464OkDZ-twzaw=.1573f75c-b017-4fd6-9eaf-34668a77781a@github.com>
Message-ID: <zZt5yjGpR7eymFJInHjZeor-B7fgbvp6nf8SLm0DGvU=.32aa2176-fcb1-473e-9301-3536a2da5355@github.com>

On Thu, 27 Oct 2022 15:50:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On macOS, perform file name normalization if and only if a specific system property is set.

This pull request has now been integrated.

Changeset: 25dfcbde
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25dfcbdea521f2963de47fa3ae0fe1b602e62fee
Stats:     48 lines in 3 files changed: 33 ins; 0 del; 15 mod

8289689: (fs) Re-examine the need for normalization to Unicode Normalization Format D (macOS)

Reviewed-by: jpai, alanb

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

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

From bpb at openjdk.org  Thu Nov  3 15:59:31 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Nov 2022 15:59:31 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v3]
In-Reply-To: <gjsus-b_Bi2MQbSGKeMpOeP-MZpBQ9hwMbmiGh6qjds=.3650e1aa-3996-4ef5-9a63-13910276f194@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <hCh5fVLPnKiY8958b5b1GTN-FWlMnmY2r28BpRiRmDI=.61d32f06-1c5e-4781-a377-03fe2fa32de1@github.com>
 <gjsus-b_Bi2MQbSGKeMpOeP-MZpBQ9hwMbmiGh6qjds=.3650e1aa-3996-4ef5-9a63-13910276f194@github.com>
Message-ID: <4w4Tb8_VlsWKgCBROG--cutAIbPFGe8hUrjfxutzHbI=.c4e217df-b0d4-4eca-b5cd-65ac60c0eaef@github.com>

On Thu, 3 Nov 2022 12:19:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I note in passing that in Java code comments we call macOS all sorts of ways. Given the history of that OS naming, would there be any value in cleaning it up someday? Maybe we could be more consistent at least in java.base.

Indeed it seems to be variously Mac OS, Mac OS X, OS X, and now macOS.

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

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

From bpb at openjdk.org  Thu Nov  3 15:59:36 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Nov 2022 15:59:36 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v2]
In-Reply-To: <LbmsvjBGIZ9iNWDYjJiIwhZr6e1jVuSU9r0R5AaNqt8=.a5671c25-194c-4a3d-bf8e-17e98997c0c9@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <N91fGkw-UVl67RR9ZeEM3p7KrSEmXWcLh-av0RABaw8=.aa941c91-471f-4e59-9646-ce2a0b9a0c56@github.com>
 <LbmsvjBGIZ9iNWDYjJiIwhZr6e1jVuSU9r0R5AaNqt8=.a5671c25-194c-4a3d-bf8e-17e98997c0c9@github.com>
Message-ID: <X9YrqZoX8Dunlw2pwD9lidGcTW8PhI7XP804ZP7KePM=.88d4cb90-1b81-479f-9da9-aafcca599c96@github.com>

On Tue, 1 Nov 2022 07:45:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge
>>  - 8295753: Use UnixDirectoryStream; compare UnixFileKeys; add SecurityManager
>>  - 8295753: (fs) UnixPath::toRealPath does not return correct case when links not followed
>
> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 882:
> 
>> 880:         // entry in the same directory which has an equal key
>> 881:         for (int i = 0; i < result.getNameCount(); i++ ) {
>> 882:             UnixPath elt = result.getName(i);
> 
> Minor nit but the the naming above is "element", it switches to "elt" here.

This was also fixed in 49d18c6a39d9d70b7da91c5b4b3740ba3c890948.

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

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

From bpb at openjdk.org  Thu Nov  3 16:43:59 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Nov 2022 16:43:59 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v4]
In-Reply-To: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
Message-ID: <1m3LP0jor91bgzNgu9SUQQSWQayGOWLM4_squvQWOTY=.41b264b5-8bd2-4c71-a924-cf0ef9ce472c@github.com>

> On macOS, ensure that the components of the `Path` returned by `UnixPath::toRealPath` have the case retained by the file system as opposed to that of the representation present in the `UnixPath` instance.

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

  8295753: More cleanup of UnixPath

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10843/files
  - new: https://git.openjdk.org/jdk/pull/10843/files/49d18c6a..c193b3b4

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

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

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

From bpb at openjdk.org  Thu Nov  3 16:44:03 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Nov 2022 16:44:03 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v3]
In-Reply-To: <xGfec2fNpVnEGo3e8EiFcgEy6yntsL9sC4hcUA9Yhy8=.62921280-fe88-486a-bff1-11d12efd5dc5@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <hCh5fVLPnKiY8958b5b1GTN-FWlMnmY2r28BpRiRmDI=.61d32f06-1c5e-4781-a377-03fe2fa32de1@github.com>
 <xGfec2fNpVnEGo3e8EiFcgEy6yntsL9sC4hcUA9Yhy8=.62921280-fe88-486a-bff1-11d12efd5dc5@github.com>
Message-ID: <d2jvLdwWfJiankCfqPMf1-A8JjVVQ_8J0tLc_h7rl0g=.dd7ce5f6-a53e-4572-8f21-f6d6128a01b7@github.com>

On Thu, 3 Nov 2022 11:40:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8295753: Clean up UnixPath; rename retentive to preserving
>
> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 814:
> 
>> 812: 
>> 813:     @Override
>> 814:     @SuppressWarnings("removal")
> 
> I assume this can be removed.

Removed in c193b3b48f56e2c581efaf212f2770c9add36a0a.

> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 876:
> 
>> 874:         UnixPath path = fs.rootDirectory();
>> 875: 
>> 876:         SecurityManager sm = System.getSecurityManager();
> 
> I assume this can be removed too.

Yes, in c193b3b48f56e2c581efaf212f2770c9add36a0a.

> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 893:
> 
>> 891:             UnixPath elementPath = path.resolve(element);
>> 892: 
>> 893:             // Derive element key
> 
> You might want to re-visit the comments at L890 and 893 and there is no derivation, instead it just gets the file key. The API allows is to be null but the Unix implementation is always non-nulll.

Revised in c193b3b48f56e2c581efaf212f2770c9add36a0a.

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

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

From bpb at openjdk.org  Thu Nov  3 16:44:05 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Nov 2022 16:44:05 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v3]
In-Reply-To: <pRI8zhTQyLWk-NWc4ltAiCZgrtqGDGkaKhSPZxoDiHQ=.5473ef12-01eb-4121-b47e-6de4953df6d9@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <hCh5fVLPnKiY8958b5b1GTN-FWlMnmY2r28BpRiRmDI=.61d32f06-1c5e-4781-a377-03fe2fa32de1@github.com>
 <xGfec2fNpVnEGo3e8EiFcgEy6yntsL9sC4hcUA9Yhy8=.62921280-fe88-486a-bff1-11d12efd5dc5@github.com>
 <pRI8zhTQyLWk-NWc4ltAiCZgrtqGDGkaKhSPZxoDiHQ=.5473ef12-01eb-4121-b47e-6de4953df6d9@github.com>
Message-ID: <vrc1sWTOAXtXeQi3Ed2kJu9NUL_og7rNVg0RjDoWTKA=.9c9f88d9-a7f2-47da-afdf-0cc937a217a9@github.com>

On Thu, 3 Nov 2022 12:10:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 907:
>> 
>>> 905:             DirectoryStream.Filter<Path> filter = (p) -> { return true; };
>>> 906:             try (DirectoryStream<Path> entries =
>>> 907:                 getFileSystem().provider().newDirectoryStream(path, filter)) {
>> 
>> I think the algorithm is correct, just need to fix the strange indentation at 907 as it looks like getFileSystem()... is in the block.
>
>> I think the algorithm is correct, just need to fix the strange intend at 907.
> 
> I assume you meant _indent(ation)_. If so, then I wonder what you'd consider as acceptable formatting here. Could `var` help not solve this problem by making 906-907 a one-liner instead? Or this would be too unusual for this class?

Indentation modified in c193b3b48f56e2c581efaf212f2770c9add36a0a. There is no use of `var` in this class so far, thus although it is a good idea, `var` is not used here, either.

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

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

From dfuchs at openjdk.org  Thu Nov  3 17:04:34 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Nov 2022 17:04:34 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v6]
In-Reply-To: <hRas8QHjcVFW_wrw8D9EOE2kz3ILlJIWn-B0OrOztCw=.61170e37-c332-47fb-927b-d5965cd7192d@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <hRas8QHjcVFW_wrw8D9EOE2kz3ILlJIWn-B0OrOztCw=.61170e37-c332-47fb-927b-d5965cd7192d@github.com>
Message-ID: <ntBnP-l-V6CfTr9TVAcH6OQpmhOLVuJMXK22ANBCjJw=.484a5f93-0df4-4e63-9f9a-a0e2ef0392c1@github.com>

On Thu, 3 Nov 2022 15:36:58 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed buffer output

The changes look good. Please make sure to verify that the test is stable, and validate that the traces you see are the traces that you expect, before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

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

From alanb at openjdk.org  Thu Nov  3 17:37:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Nov 2022 17:37:34 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v6]
In-Reply-To: <hRas8QHjcVFW_wrw8D9EOE2kz3ILlJIWn-B0OrOztCw=.61170e37-c332-47fb-927b-d5965cd7192d@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <hRas8QHjcVFW_wrw8D9EOE2kz3ILlJIWn-B0OrOztCw=.61170e37-c332-47fb-927b-d5965cd7192d@github.com>
Message-ID: <3VQ9guhTVgwuEQ2UGgZHCY_WwalEo62FSHq1LV3ip8Q=.d7b50c72-133a-40a3-89ed-f2d6f70dab74@github.com>

On Thu, 3 Nov 2022 15:36:58 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed buffer output

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 112:

> 110:             }
> 111:             for (int i = 0; i < MAX_TRIES; i++) {
> 112:                 /* Test 3: not connected so ICMP port unreachable should not be received */

For readability it might be better to restore the break between Test 2 and Test 3 so that it's easier to see where Test 3 starts. The updated test is a bit hard to follow because the original comments have been moved into the loop and maybe better to just leave them where they were, as in Test 2.

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 155:

> 153:                 buf.get(bytes);
> 154:                 String message = new String(bytes);
> 155:                 if (sa != null) {

L151-154 should be moved into the if (sa != null) { ... } as there are no bytes read when the sender is null.

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 158:

> 156:                     System.out.format("received %s at %s from %s%n", message, datagramChannel.getLocalAddress(), sa);
> 157:                 }
> 158:                 //If any received data contains the message from sendDatagram then return false

Missing space in "//If", best to keep comments consistent where you can.

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

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

From alanb at openjdk.org  Thu Nov  3 17:50:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Nov 2022 17:50:34 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v4]
In-Reply-To: <1m3LP0jor91bgzNgu9SUQQSWQayGOWLM4_squvQWOTY=.41b264b5-8bd2-4c71-a924-cf0ef9ce472c@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <1m3LP0jor91bgzNgu9SUQQSWQayGOWLM4_squvQWOTY=.41b264b5-8bd2-4c71-a924-cf0ef9ce472c@github.com>
Message-ID: <ehchVZFfNpzTbyo0UGuePZLJpawWg_qoXFYq3jsz7zc=.ccc3ed9e-98ab-404d-9dbe-60828e765583@github.com>

On Thu, 3 Nov 2022 16:43:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On macOS, ensure that the components of the `Path` returned by `UnixPath::toRealPath` have the case retained by the file system as opposed to that of the representation present in the `UnixPath` instance.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295753: More cleanup of UnixPath

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.org  Fri Nov  4 07:57:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 4 Nov 2022 07:57:44 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v3]
In-Reply-To: <vrc1sWTOAXtXeQi3Ed2kJu9NUL_og7rNVg0RjDoWTKA=.9c9f88d9-a7f2-47da-afdf-0cc937a217a9@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <hCh5fVLPnKiY8958b5b1GTN-FWlMnmY2r28BpRiRmDI=.61d32f06-1c5e-4781-a377-03fe2fa32de1@github.com>
 <xGfec2fNpVnEGo3e8EiFcgEy6yntsL9sC4hcUA9Yhy8=.62921280-fe88-486a-bff1-11d12efd5dc5@github.com>
 <pRI8zhTQyLWk-NWc4ltAiCZgrtqGDGkaKhSPZxoDiHQ=.5473ef12-01eb-4121-b47e-6de4953df6d9@github.com>
 <vrc1sWTOAXtXeQi3Ed2kJu9NUL_og7rNVg0RjDoWTKA=.9c9f88d9-a7f2-47da-afdf-0cc937a217a9@github.com>
Message-ID: <tltPu6rQ5J6mvcybN5AHDQbt179L9FJXlmxQhVsx9yA=.700061a9-7bce-4bee-842c-0190294b9eb9@github.com>

On Thu, 3 Nov 2022 16:38:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> I think the algorithm is correct, just need to fix the strange intend at 907.
>> 
>> I assume you meant _indent(ation)_. If so, then I wonder what you'd consider as acceptable formatting here. Could `var` help not solve this problem by making 906-907 a one-liner instead? Or this would be too unusual for this class?
>
> Indentation modified in c193b3b48f56e2c581efaf212f2770c9add36a0a. There is no use of `var` in this class so far, thus although it is a good idea, `var` is not used here, either.

> If so, then I wonder what you'd consider as acceptable formatting here. Could `var` help not solve this problem by making 906-907 a one-liner instead? Or this would be too unusual for this class?

The main thing when reading this code is to satisfied that it implements the scan correctly and to see how it behaves when it can't open a directory or read the attributes of one of the entries in the directory. The issue with the version that were discussing is that it wasn't immediately obvious which code was in the try resources specification vs. try block. He's changed the indent so it is more obvious now, personally I would have put it one line and renamed it to "provider" so that it's the same name used elsewhere in this code.

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

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

From duke at openjdk.org  Fri Nov  4 12:20:33 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Fri, 4 Nov 2022 12:20:33 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v7]
In-Reply-To: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
Message-ID: <7s-69ShQJg8-k4n7CjwqEP8zNa3ocAkYgMLlgDx8b3k=.b40cb9f9-afd7-4442-b452-5751b6d98e85@github.com>

> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
> 
> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.

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

  cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10851/files
  - new: https://git.openjdk.org/jdk/pull/10851/files/43277609..2fbf57a7

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

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

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

From msheppar at openjdk.org  Fri Nov  4 12:30:31 2022
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 4 Nov 2022 12:30:31 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v7]
In-Reply-To: <7s-69ShQJg8-k4n7CjwqEP8zNa3ocAkYgMLlgDx8b3k=.b40cb9f9-afd7-4442-b452-5751b6d98e85@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <7s-69ShQJg8-k4n7CjwqEP8zNa3ocAkYgMLlgDx8b3k=.b40cb9f9-afd7-4442-b452-5751b6d98e85@github.com>
Message-ID: <f-hAYGo3Ba1LRsJ4YE6E1p-VdyZbC4cR_DAAPqAMh7o=.4602243c-456d-4a3d-9e48-ed8cc909e621@github.com>

On Fri, 4 Nov 2022 12:20:33 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

you might consider a refactor extract method, for each of the test scenarios such that 
each loop contains an invocation of a static method encapsulating that test scenario 
For example, scenario 1 == testNoPUEUnconnected, scenario 2 == testPUEConnected, 
scenario 3 == testNoPUEDisconnected, and each method has a brief description 
of the test scenario and retry policy. As such, first test retry loop might look like





       try {
            dc.configureBlocking(false);
            dc.register(sel, SelectionKey.OP_READ);

            for (int i = 0; i < MAX_TRIES; i++) {
                if (!testNoPUEUnconnected(dc, refuser, sel, i)) {
                    break;
                }
              }
       ?.

    /*
     * Send a datagram to non existent unconnected UDP end point 
     * This shouldn't result in an PortUnreachableException
     * Handle unexpected read events on the senders DC with
     * retry when message received is external. Ignore
     * receipt of own message
     */
    static boolean testNoPUEUnconnected (DatagramChannel sender,
                                         SocketAddress recipient,
                                         Selector selector,
                                         int retryCount) throws IOException {
        /* Test 1: not connected so ICMP port unreachable should not be received */
        sendDatagram(sender, recipient);
        int n = selector.select(2000);
        if (n > 0) {
                    boolean receivedExternalDatagram = checkUnexpectedWakeup(selector.selectedKeys());
                    selector.selectedKeys().clear();
                    if (receivedExternalDatagram) {
                        if (i < MAX_TRIES - 1) {
                           return true;
                    }
                    // BindException will be thrown if another service is using
                    // our expected refuser port, cannot run just exit.
                    DatagramChannel.open().bind(refuser).close();
                    throw new RuntimeException("Unexpected wakeup");
                }
        }
        return false;
    }

//  E&OE ? I haven?t tested the above 

Or alternatively encapsulate the retry loop into the scenario methods also ??

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

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

From mik3hall at gmail.com  Fri Nov  4 12:51:33 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 4 Nov 2022 07:51:33 -0500
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
Message-ID: <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>



>> 
>> 
>> 
>> I had a thought for some code to try this on but seem to get a number of build errors now.
>> 
>> http://mikehall.pairserver.com/errors10140.txt <http://mikehall.pairserver.com/errors10140.txt> <http://mikehall.pairserver.com/errors10140.txt <http://mikehall.pairserver.com/errors10140.txt>>
>> 
>> Using the GitHub Desktop app to change to pr/10140
>> 
>> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221102/d5ad452a/attachment.htm <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221102/d5ad452a/attachment.htm>>
> 
> You are using xcode 14 with sdk for macos Ventura hence having issues. that's orthogonal to this PR.
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/10140 <https://git.openjdk.org/jdk/pull/10140>
What was suggested as the error here - isn?t. For me this doesn?t build with the errors given in the link. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221104/adeabdb0/attachment.htm>

From bpb at openjdk.org  Fri Nov  4 16:03:40 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 4 Nov 2022 16:03:40 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v5]
In-Reply-To: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
Message-ID: <8Vo0zoAY9wnYzAUrnHc6_F4bZuCq8xRJgOCFGPCEvTk=.e09e29b4-7c04-4018-bddd-39956e84db86@github.com>

> On macOS, ensure that the components of the `Path` returned by `UnixPath::toRealPath` have the case retained by the file system as opposed to that of the representation present in the `UnixPath` instance.

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

  8295753: Minor tweak for try-resources block clarity

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10843/files
  - new: https://git.openjdk.org/jdk/pull/10843/files/c193b3b4..275c9f50

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

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

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

From alanb at openjdk.org  Fri Nov  4 16:09:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 4 Nov 2022 16:09:36 GMT
Subject: RFR: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed [v5]
In-Reply-To: <8Vo0zoAY9wnYzAUrnHc6_F4bZuCq8xRJgOCFGPCEvTk=.e09e29b4-7c04-4018-bddd-39956e84db86@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
 <8Vo0zoAY9wnYzAUrnHc6_F4bZuCq8xRJgOCFGPCEvTk=.e09e29b4-7c04-4018-bddd-39956e84db86@github.com>
Message-ID: <Yhq1XRubNDD9caGrp09JeeSllgDqY1fSyZk3Wjgs4wU=.1d8ec237-bebb-4059-86bd-51e5113315f6@github.com>

On Fri, 4 Nov 2022 16:03:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On macOS, ensure that the components of the `Path` returned by `UnixPath::toRealPath` have the case retained by the file system as opposed to that of the representation present in the `UnixPath` instance.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295753: Minor tweak for try-resources block clarity

Marked as reviewed by alanb (Reviewer).

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

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

From bpb at openjdk.org  Fri Nov  4 17:35:09 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 4 Nov 2022 17:35:09 GMT
Subject: Integrated: 8295753: (fs) UnixPath::toRealPath does not return correct
 case when links not followed
In-Reply-To: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
References: <6WGVJ1L_0aM7tp0LgFMbZy_L4bJ7Gr80mlg0ZKk9piI=.6fa46e68-3ae7-4582-a651-8b0b1d259aa1@github.com>
Message-ID: <GF4MwBcBgDH2ydQovhpPsK-0jJP_eFRcmIVOywH8UZ8=.5b794069-7874-4a45-be61-72ef6dfc1f07@github.com>

On Mon, 24 Oct 2022 22:58:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On macOS, ensure that the components of the `Path` returned by `UnixPath::toRealPath` have the case retained by the file system as opposed to that of the representation present in the `UnixPath` instance.

This pull request has now been integrated.

Changeset: 5b7e7064
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b7e70645b311b7060da20cb7ca813df34834332
Stats:     151 lines in 4 files changed: 130 ins; 5 del; 16 mod

8295753: (fs) UnixPath::toRealPath does not return correct case when links not followed

Reviewed-by: alanb

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

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

From mcimadamore at openjdk.org  Fri Nov  4 18:23:17 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Nov 2022 18:23:17 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v2]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <IxHlukr_bx6t1miZypvnq_8eWAgyouVs1mdNOhFW3bE=.4efc799a-206e-4f05-a28f-fab819cd4334@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

 - Merge branch 'master' into PR_20
 - Merge branch 'master' into PR_20
 - Merge pull request #14 from minborg/small-javadoc
   
   Update some javadocs
 - Update some javadocs
 - Revert some javadoc changes
 - Merge branch 'master' into PR_20
 - Fix benchmark and test failure
 - Merge pull request #13 from minborg/revert-factories
   
   Revert MemorySegment factories
 - Update javadocs after comments
 - Revert MemorySegment factories
 - ... and 7 more: https://git.openjdk.org/jdk/compare/7eb59e41...3d933028

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/ac7733da..3d933028

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

  Stats: 51371 lines in 672 files changed: 16181 ins; 32391 del; 2799 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

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

From duke at openjdk.org  Fri Nov  4 18:39:45 2022
From: duke at openjdk.org (duke)
Date: Fri, 4 Nov 2022 18:39:45 GMT
Subject: Withdrawn: 8288627: [AIX] Implement WatchService using system library
In-Reply-To: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com>
References: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com>
Message-ID: <UvVnx99YnMJqYkJiSHT5HBo6Q89VzE_-5ARAFuBsChs=.4107e14d-0d24-403a-96cc-39ea3c238cf8@github.com>

On Fri, 24 Jun 2022 15:17:47 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> This PR begins an effort to re-implement the WatchService API on AIX using 'AIX Event Infrastructure' (AHAFS). The initial motivation for doing so was to address errors found by some internal testing in the implementation based on PollingWatchService.java.
> 
> I am submitting these changes before they are fully complete because (1) it represents a fairly large change that mostly works well, and could easily be improved upon in the future; (2) to get some early feedback on the changes so the final review process is quicker. My expected plan is to merge these changes after review, add any remaining test failures to a problem list, and return to them soon.
> 
> ### Testing
> I am waiting for confirmation that this re-implementation passes the internal tests we saw failing. Initial results look promising. In addition, I see the following failing tests from `test/jdk/java/nio/file/WatchService`:
> 
> - Basic.java fails at testTwoWatchers. Having two WatchService instances registered with the same file, will require some additional work to be supported with AHAFS. This is currently a limitation of this implementation.
> - DeleteInterference.java fails for the same reason as above.
> - UpdateInterference.java fails for no good reason that I can deduce. Logging the test's progress shows that it doesn't seem to leave [the main loop](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/WatchService/UpdateInterference.java#L97-L111), but that it makes is to within 1ms of doing so.

This pull request has been closed without being integrated.

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

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

From jvernee at openjdk.org  Sat Nov  5 19:48:32 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 5 Nov 2022 19:48:32 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v2]
In-Reply-To: <IxHlukr_bx6t1miZypvnq_8eWAgyouVs1mdNOhFW3bE=.4efc799a-206e-4f05-a28f-fab819cd4334@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IxHlukr_bx6t1miZypvnq_8eWAgyouVs1mdNOhFW3bE=.4efc799a-206e-4f05-a28f-fab819cd4334@github.com>
Message-ID: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com>

On Fri, 4 Nov 2022 18:23:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into PR_20
>  - Merge branch 'master' into PR_20
>  - Merge pull request #14 from minborg/small-javadoc
>    
>    Update some javadocs
>  - Update some javadocs
>  - Revert some javadoc changes
>  - Merge branch 'master' into PR_20
>  - Fix benchmark and test failure
>  - Merge pull request #13 from minborg/revert-factories
>    
>    Revert MemorySegment factories
>  - Update javadocs after comments
>  - Revert MemorySegment factories
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/e1e4e45b...3d933028

Some preliminary comments about some changes I think are missing from this PR (noticed while I was making a patch for the VM changes)

I will do a more thorough review after the changes from https://github.com/openjdk/panama-foreign/pull/750 are included as well.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 474:

> 472:         long bbAddress = NIO_ACCESS.getBufferAddress(bb);
> 473:         Object base = NIO_ACCESS.getBufferBase(bb);
> 474:         UnmapperProxy unmapper = NIO_ACCESS.unmapper(bb);

Looks like here is also missing the fix that rejects StringCharBuffer: https://github.com/openjdk/panama-foreign/pull/741 I think that is good to include as well.

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 477:

> 475:                 case UNBOX_ADDRESS -> emitUnboxAddress();
> 476:                 case DUP -> emitDupBinding();
> 477:                 case CAST -> emitCast((Binding.Cast) binding);

This contains the CAST binding, but not the accompanying VM changes from: https://github.com/openjdk/panama-foreign/pull/720 which removes the now dead code. Preferably both changes go together (and the code removal is pretty trivial, so I suggest including it here)

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 491:

> 489:         emitLoad(highLevelType, paramIndex2ParamSlot[paramIndex]);
> 490: 
> 491:         if (shouldAcquire(paramIndex)) {

I can't comment on the actual line below, but this is also missing the fix from: https://github.com/openjdk/panama-foreign/pull/739 (that is a Java-only change as well). I suggest adding that as well.

src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java line 165:

> 163:                 assert forArguments : "no stack returns";
> 164:                 // stack
> 165:                 long alignment = Math.max(layout.byteAlignment(), STACK_SLOT_SIZE);

This is also missing part of the changes from: https://github.com/openjdk/panama-foreign/pull/728/ but other changes to the shared code are present. The `layout` parameter is not needed here. (see the changes to this file in the original PR)

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

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

From alanb at openjdk.org  Mon Nov  7 07:29:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Nov 2022 07:29:34 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
Message-ID: <tBLzZ5_4YFkD5zjGPJFZeVyAi06bFWMt67o1gS8rnlk=.67723a22-26a8-489d-a443-1e15f5ed0c3e@github.com>

On Wed, 19 Oct 2022 06:48:05 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> This is an implementation of `WatchService` based on File System Events API that is capable of generating events whenever a change occurs in an interesting directory or underneath it. Since the API naturally supports "recursive" watch, the `FILE_TREE` is supported by the watch service. 
>> 
>> Some things of note:
>> * There's one "service" thread per `WatchService` instance that is inactive unless changes occur in the watched directory. The changes are grouped by introducing a time delay between when they occurred and when they are reported, which is controlled by the sensitivity modifier of the watch service.
>> * Since FSEvents API reports directories only, the watch service keeps a snapshot (hierarchical if necessary) of the files in the directory being watched. The snapshot gets updated when an event in that directory or underneath it gets delivered. File changes are detected by comparing "last modified" time with a millisecond precision (`BasicFileAttributes.lastModifiedTime()`).
>> * There is a slight complication with the move of an entire directory hierarchy: FSEvents API only reports about the containing directory of that move and not about any of the directories actually moved. There's a separate test for that (`Move.java`).
>> * The code is careful not to do any I/O (such as reading the contents of a directory or attributes of a file) unless unavoidable. Any deviation from this line should be considered a bug (of, arguably, low priority).
>> * The native part consists mostly of API wrappers with one exception of the callback function invoked by the system to report the events that occurred. The sole task of the function is to convert from C strings to Java strings and pass the array of affected directories to Java code. This can be rewritten if desired to make the code more future-proof.
>> 
>> This commit leaves `PollingWatchService` unused. I'm not sure if I should/can do anything about it. Any advice is welcomed.
>> 
>> ### Testing
>> 
>> * Tested by running `test/jdk/java/nio/file` and `test/jdk/jdk/nio` on MacOS 10.15.7 (x64) and `test/jdk/java/nio/` plus `test/jdk/jdk/nio` on MacOS 12.5.1 (aarch64).
>> * Also verified that new tests pass on Linux and Windows.
>> * This code (albeit in a slightly modified form) has been in use at JetBrains for around half a year and a few bugs have been found and fixed during that time period.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected coding style

I don't test/jdk/java/nio/file/WatchService/JNIChecks.java should be integrated as is. It's okay to run tests with -Xcheck:jni but it would be a lot more maintainable to just add `@run main/othervm -Xcheck:jni XXX` to the existing tests.  Basic.java is the main unit test for this API and having that re-run with -Xcheck:jni may be enough here. It's relatively long running on some platforms so we could put give its its own run tag, as in:


-/* @test
+/* @test id = default
  * @bug 4313887 6838333 7017446 8011537 8042470
  * @summary Unit test for java.nio.file.WatchService
  * @library ..
  * @run main Basic
  */
 
+/* @test id=checkjni
+ * @library ..
+ * @run main/other -Xcheck:jni Basic
+ */
+


Note that this runs it with -Xcheck:jni on all platforms, it doesn't need to be restricted to macOS.

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

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

From mcimadamore at openjdk.org  Mon Nov  7 09:24:04 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 09:24:04 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v2]
In-Reply-To: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IxHlukr_bx6t1miZypvnq_8eWAgyouVs1mdNOhFW3bE=.4efc799a-206e-4f05-a28f-fab819cd4334@github.com>
 <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com>
Message-ID: <uwIHMZkXTUhF7LQ28QNk7LI2Vls1fyZ6t24DDkP1vpI=.526479a8-c268-41f0-ab47-74b5e06f8311@github.com>

On Sat, 5 Nov 2022 18:02:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into PR_20
>>  - Merge branch 'master' into PR_20
>>  - Merge pull request #14 from minborg/small-javadoc
>>    
>>    Update some javadocs
>>  - Update some javadocs
>>  - Revert some javadoc changes
>>  - Merge branch 'master' into PR_20
>>  - Fix benchmark and test failure
>>  - Merge pull request #13 from minborg/revert-factories
>>    
>>    Revert MemorySegment factories
>>  - Update javadocs after comments
>>  - Revert MemorySegment factories
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d314527d...3d933028
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 477:
> 
>> 475:                 case UNBOX_ADDRESS -> emitUnboxAddress();
>> 476:                 case DUP -> emitDupBinding();
>> 477:                 case CAST -> emitCast((Binding.Cast) binding);
> 
> This contains the CAST binding, but not the accompanying VM changes from: https://github.com/openjdk/panama-foreign/pull/720 which removes the now dead code. Preferably both changes go together (and the code removal is pretty trivial, so I suggest including it here)

Why did the normalization test passed even w/o VM changes? Is that because the VM code changes are just removing what is now dead code, right?

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

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

From mcimadamore at openjdk.org  Mon Nov  7 09:30:19 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 09:30:19 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v2]
In-Reply-To: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IxHlukr_bx6t1miZypvnq_8eWAgyouVs1mdNOhFW3bE=.4efc799a-206e-4f05-a28f-fab819cd4334@github.com>
 <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com>
Message-ID: <gjk9ZLzpYbu9cVSzfcq6DQ2NDzZHzlTznd-24UBFLgM=.710eb153-1731-415b-87b2-4d2fedbb32bb@github.com>

On Sat, 5 Nov 2022 18:04:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into PR_20
>>  - Merge branch 'master' into PR_20
>>  - Merge pull request #14 from minborg/small-javadoc
>>    
>>    Update some javadocs
>>  - Update some javadocs
>>  - Revert some javadoc changes
>>  - Merge branch 'master' into PR_20
>>  - Fix benchmark and test failure
>>  - Merge pull request #13 from minborg/revert-factories
>>    
>>    Revert MemorySegment factories
>>  - Update javadocs after comments
>>  - Revert MemorySegment factories
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/1fd35b8a...3d933028
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 491:
> 
>> 489:         emitLoad(highLevelType, paramIndex2ParamSlot[paramIndex]);
>> 490: 
>> 491:         if (shouldAcquire(paramIndex)) {
> 
> I can't comment on the actual line below, but this is also missing the fix from: https://github.com/openjdk/panama-foreign/pull/739 (that is a Java-only change as well). I suggest adding that as well.

Few changes were missing - but the `dontrelease` tests was passing... odd

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

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

From mcimadamore at openjdk.org  Mon Nov  7 09:42:25 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 09:42:25 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v2]
In-Reply-To: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IxHlukr_bx6t1miZypvnq_8eWAgyouVs1mdNOhFW3bE=.4efc799a-206e-4f05-a28f-fab819cd4334@github.com>
 <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com>
Message-ID: <09WcJa8UMXNVYkW_eI7w-tW7fnZ6KXt1gt_4cu5Y2KE=.8be58947-1169-42e0-8c6f-45b66ff63c10@github.com>

On Sat, 5 Nov 2022 18:40:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into PR_20
>>  - Merge branch 'master' into PR_20
>>  - Merge pull request #14 from minborg/small-javadoc
>>    
>>    Update some javadocs
>>  - Update some javadocs
>>  - Revert some javadoc changes
>>  - Merge branch 'master' into PR_20
>>  - Fix benchmark and test failure
>>  - Merge pull request #13 from minborg/revert-factories
>>    
>>    Revert MemorySegment factories
>>  - Update javadocs after comments
>>  - Revert MemorySegment factories
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d8bb7119...3d933028
>
> src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java line 165:
> 
>> 163:                 assert forArguments : "no stack returns";
>> 164:                 // stack
>> 165:                 long alignment = Math.max(layout.byteAlignment(), STACK_SLOT_SIZE);
> 
> This is also missing part of the changes from: https://github.com/openjdk/panama-foreign/pull/728/ but other changes to the shared code are present. The `layout` parameter is not needed here. (see the changes to this file in the original PR)

Actually, this patch is missing most of the stuff in PR 728. I was under the impression that, in order to fully support that, some VM changes were needed (e.g. to have better granularity in call shuffling - as per https://github.com/openjdk/panama-foreign/pull/699). As a result, this PR only contains changes to SharedUtil (to remove unused alignment functions) - but nothing else.

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

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

From mcimadamore at openjdk.org  Mon Nov  7 09:47:34 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 09:47:34 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v3]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <JcunES0_tenzQnCZPFDzM3kKAtKLaOXmOz10mujtzmk=.850e7685-c88c-44cc-8053-5f472aa0f7d8@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

 - Fix mismmatched acquire/release in BindingSpecializer
 - Fix MemorySegment.ofBuffer when applied to StringCharBuffer
 - Remove VM dead code after implementation of Binding.Cast

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/3d933028..e8b95f83

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

  Stats: 51 lines in 6 files changed: 12 ins; 34 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

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

From mkartashev at openjdk.org  Mon Nov  7 12:08:34 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Mon, 7 Nov 2022 12:08:34 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <tBLzZ5_4YFkD5zjGPJFZeVyAi06bFWMt67o1gS8rnlk=.67723a22-26a8-489d-a443-1e15f5ed0c3e@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <tBLzZ5_4YFkD5zjGPJFZeVyAi06bFWMt67o1gS8rnlk=.67723a22-26a8-489d-a443-1e15f5ed0c3e@github.com>
Message-ID: <RYdGAgze4i8YwExqRMMIsZ7HfCx193v5-4uA7m81Z8A=.279bb5aa-0dc4-47b0-8869-2abc8017e275@github.com>

On Mon, 7 Nov 2022 07:27:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Basic.java is the main unit test for this API and having that re-run with -Xcheck:jni may be enough here. 
I'm OK with running just `Basic.java`, but I don't understand how adding `-Xcheck:jni` to `@run` will make this work because we need the test to check the output for warnings from those checks.

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

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

From mcimadamore at openjdk.org  Mon Nov  7 12:29:37 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 12:29:37 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v4]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <b8jy-BY9ykLzHYS5hmf8_rNZvY6wLflhCUeWQF3_1qs=.2e9bb0a3-c25d-495c-98a5-14b06bd15550@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Add missing tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/e8b95f83..0c70da2c

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

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

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

From jvernee at openjdk.org  Mon Nov  7 13:45:33 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 7 Nov 2022 13:45:33 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v2]
In-Reply-To: <09WcJa8UMXNVYkW_eI7w-tW7fnZ6KXt1gt_4cu5Y2KE=.8be58947-1169-42e0-8c6f-45b66ff63c10@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IxHlukr_bx6t1miZypvnq_8eWAgyouVs1mdNOhFW3bE=.4efc799a-206e-4f05-a28f-fab819cd4334@github.com>
 <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com>
 <09WcJa8UMXNVYkW_eI7w-tW7fnZ6KXt1gt_4cu5Y2KE=.8be58947-1169-42e0-8c6f-45b66ff63c10@github.com>
Message-ID: <b1ckc2kdUNotWjqf-qSLlZsKK-LrBe90YD5JEIw8M58=.61cda3cf-a617-4cc1-8875-97dda762dd4b@github.com>

On Mon, 7 Nov 2022 09:40:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java line 165:
>> 
>>> 163:                 assert forArguments : "no stack returns";
>>> 164:                 // stack
>>> 165:                 long alignment = Math.max(layout.byteAlignment(), STACK_SLOT_SIZE);
>> 
>> This is also missing part of the changes from: https://github.com/openjdk/panama-foreign/pull/728/ but other changes to the shared code are present. The `layout` parameter is not needed here. (see the changes to this file in the original PR)
>
> Actually, this patch is missing most of the stuff in PR 728. I was under the impression that, in order to fully support that, some VM changes were needed (e.g. to have better granularity in call shuffling - as per https://github.com/openjdk/panama-foreign/pull/699). As a result, this PR only contains changes to SharedUtil (to remove unused alignment functions) - but nothing else.

699 is not needed for this. 728 is a pure Java change that simply rejects layouts that don't have their natural alignment (so, it will rejects packed structs for instance, since the implementation doesn't support them on all platforms). All the other changes from 728 are here (most notably the code in AbstractLinker that checks the alignment), except the change that ignores the `layout` here and turns the code around the line above into an `assert`.

The mac stack spilling patch requires 699 though (https://github.com/openjdk/panama-foreign/pull/746). I will put that in the PR with the VM changes.

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

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

From mcimadamore at openjdk.org  Mon Nov  7 14:06:39 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 14:06:39 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v2]
In-Reply-To: <b1ckc2kdUNotWjqf-qSLlZsKK-LrBe90YD5JEIw8M58=.61cda3cf-a617-4cc1-8875-97dda762dd4b@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IxHlukr_bx6t1miZypvnq_8eWAgyouVs1mdNOhFW3bE=.4efc799a-206e-4f05-a28f-fab819cd4334@github.com>
 <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com>
 <09WcJa8UMXNVYkW_eI7w-tW7fnZ6KXt1gt_4cu5Y2KE=.8be58947-1169-42e0-8c6f-45b66ff63c10@github.com>
 <b1ckc2kdUNotWjqf-qSLlZsKK-LrBe90YD5JEIw8M58=.61cda3cf-a617-4cc1-8875-97dda762dd4b@github.com>
Message-ID: <PjTd9RxWhqKuuwBjjnZnYy2N2LzUablXp5QY1VWO7Vs=.35eb79fd-0d23-424a-a9fe-7fa3cdcf2697@github.com>

On Mon, 7 Nov 2022 13:43:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Actually, this patch is missing most of the stuff in PR 728. I was under the impression that, in order to fully support that, some VM changes were needed (e.g. to have better granularity in call shuffling - as per https://github.com/openjdk/panama-foreign/pull/699). As a result, this PR only contains changes to SharedUtil (to remove unused alignment functions) - but nothing else.
>
> 699 is not needed for this. 728 is a pure Java change that simply rejects layouts that don't have their natural alignment (so, it will rejects packed structs for instance, since the implementation doesn't support them on all platforms). All the other changes from 728 are here (most notably the code in AbstractLinker that checks the alignment), except the change that ignores the `layout` here and turns the code around the line above into an `assert`.
> 
> The mac stack spilling patch requires 699 though (https://github.com/openjdk/panama-foreign/pull/746). I will put that in the PR with the VM changes.

Thanks for the clarification - I will incorporate those changes as well then.

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

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

From mcimadamore at openjdk.org  Mon Nov  7 14:17:40 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 14:17:40 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v5]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <nLGKXMEfHApyxseQFp882Q-QXNxbkWcChh2Yv1COKG4=.70ef8fea-423b-4034-ad6e-026f2164f3c4@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Bring windows CallArranger in sync with panama repo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/0c70da2c..b98febff

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

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

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

From mcimadamore at openjdk.org  Mon Nov  7 15:00:02 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 15:00:02 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v6]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Make memory session a pure lifetime abstraction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/b98febff..f04be0da

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

  Stats: 2492 lines in 139 files changed: 600 ins; 771 del; 1121 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

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

From mcimadamore at openjdk.org  Mon Nov  7 15:01:39 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Nov 2022 15:01:39 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v5]
In-Reply-To: <nLGKXMEfHApyxseQFp882Q-QXNxbkWcChh2Yv1COKG4=.70ef8fea-423b-4034-ad6e-026f2164f3c4@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <nLGKXMEfHApyxseQFp882Q-QXNxbkWcChh2Yv1COKG4=.70ef8fea-423b-4034-ad6e-026f2164f3c4@github.com>
Message-ID: <7ZPsmtKqqOeItVnPztGyLhwuHi5Q9WsGI8SYzGkyL8Q=.33d63f63-9cbb-42bd-8d81-6555ed3d67d2@github.com>

On Mon, 7 Nov 2022 14:17:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bring windows CallArranger in sync with panama repo

I have incorporated additional API changes, described in this document:
http://cr.openjdk.java.net/~mcimadamore/panama/session_arenas.html

The main change is that `MemorySession` is now a pure lifetime abstraction and no longer implements `AutoCloseable`/`SegementAllocator`. Instead a new abstraction, called `Arena` should be used for deterministic deallocation use cases. This change allows several simplifications on the `MemorySession` API, as there's no more need to support non-closeable views.

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

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

From duke at openjdk.org  Mon Nov  7 16:28:11 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 7 Nov 2022 16:28:11 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v8]
In-Reply-To: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
Message-ID: <8cBPylmbjzrUbBKkMHv9uT9hVhVWMOjoO3yrgoE98Qw=.a4073de6-6dc2-4b96-a36c-4c9aaa04eab9@github.com>

> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
> 
> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.

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

 - removed dupe line
 - refactoring and cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10851/files
  - new: https://git.openjdk.org/jdk/pull/10851/files/2fbf57a7..f60a412e

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

  Stats: 169 lines in 1 file changed: 115 ins; 48 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10851.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10851/head:pull/10851

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

From duke at openjdk.org  Mon Nov  7 16:28:13 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 7 Nov 2022 16:28:13 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v7]
In-Reply-To: <7s-69ShQJg8-k4n7CjwqEP8zNa3ocAkYgMLlgDx8b3k=.b40cb9f9-afd7-4442-b452-5751b6d98e85@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <7s-69ShQJg8-k4n7CjwqEP8zNa3ocAkYgMLlgDx8b3k=.b40cb9f9-afd7-4442-b452-5751b6d98e85@github.com>
Message-ID: <2buyZ1M-Dp5pG8bKYbgNtS7AeUASLwy3RJw60PNCvdI=.01ca19f4-7497-4d8c-bb7a-b94089f09764@github.com>

On Fri, 4 Nov 2022 12:20:33 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

I refactored and cleaned up the test, it should hopefully be a lot more readable now

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

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

From psandoz at openjdk.org  Mon Nov  7 19:11:15 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 7 Nov 2022 19:11:15 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v6]
In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
Message-ID: <6pOPurF5NgGOYP73lLadj7jzY6FVrCUl9Fkh7MkBfi0=.7ecd3ff9-a2ac-474f-8270-a30bb0f56c92@github.com>

On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make memory session a pure lifetime abstraction

src/java.base/share/classes/java/lang/foreign/Arena.java line 37:

> 35:  * This session is created with the arena, and is closed when the arena is {@linkplain #close() closed}.
> 36:  * Furthermore, all the native segments {@linkplain #allocate(long, long) allocated} by the arena are associated
> 37:  * with that session.

I think we can simplify the wording by saying an arena has a session:
Suggestion:

 * An arena is a {@linkplain AutoCloseable closeable} segment allocator that has a {@link #session() memory session}.
 * The arena's session is created when the arena is created, and is closed when the arena is {@linkplain #close() closed}.
 * All native segments {@linkplain #allocate(long, long) allocated} by the arena are associated
 * with its session.

src/java.base/share/classes/java/lang/foreign/Arena.java line 65:

> 63:      * The {@link MemorySegment#address()} of the returned memory segment is the starting address of the
> 64:      * allocated off-heap memory region backing the segment. Moreover, the {@linkplain MemorySegment#address() address}
> 65:      * of the returned segment is aligned according the provided alignment constraint.

Suggestion:

    /**
     * Creates a native memory segment with the given size (in bytes) and alignment constraint (in bytes).
     * The returned segment is associated with the arena's memory session.
     * The segment's {@link MemorySegment#address() address} is the starting address of the
     * allocated off-heap memory region backing the segment, and the address is 
     * aligned according the provided alignment constraint.

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

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

From psandoz at openjdk.org  Mon Nov  7 19:23:28 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 7 Nov 2022 19:23:28 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v6]
In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
Message-ID: <m-DUj0-tpTQ8gspRH6qB27A5esSvI12S30QhZi2YOgs=.2edbc994-7ae2-4aeb-bf56-dd0728df0adf@github.com>

On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make memory session a pure lifetime abstraction

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 357:

> 355: 
> 356:     /**
> 357:      * Creates an access var handle that can be used to access a memory segment at the layout selected by the given layout path,

Suggestion:

     * Creates a var handle that can be used to access a memory segment at the layout selected by the given layout path,

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

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

From psandoz at openjdk.org  Mon Nov  7 19:34:26 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 7 Nov 2022 19:34:26 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v6]
In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
Message-ID: <_3OEoupwOnEbpnA1ApYUiH3GhzDlHyOxearctDT85a0=.493601cf-85d0-4a5d-959d-d01da03e4e83@github.com>

On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make memory session a pure lifetime abstraction

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 104:

> 102:  * Every memory segment is associated with a {@linkplain MemorySession memory session}. This ensures that access operations
> 103:  * on a memory segment cannot occur when the region of memory which backs the memory segment is no longer available
> 104:  * (e.g. after the memory session associated with the accessed memory segment is no longer {@linkplain MemorySession#isAlive() alive}.

Missing close brace:
Suggestion:

 * (e.g., after the memory session associated with the accessed memory segment is no longer {@linkplain MemorySession#isAlive() alive}).

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

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

From psandoz at openjdk.org  Mon Nov  7 19:47:42 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 7 Nov 2022 19:47:42 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v6]
In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
Message-ID: <4Sj58ZiAdyXGqIagMDMMD3dTWwjKt8pTudl1JHnwp4Q=.cf41a458-e19d-42b7-b465-b3c40db144ac@github.com>

On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make memory session a pure lifetime abstraction

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 312:

> 310:  * </table></blockquote>
> 311:  *
> 312:  * Heap segment can only be accessed using a layout whose alignment is smaller or equal to the

Suggestion:

 * Heap segments can only be accessed using a layout whose alignment is smaller or equal to the

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

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

From psandoz at openjdk.org  Mon Nov  7 20:00:39 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 7 Nov 2022 20:00:39 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v6]
In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
Message-ID: <MgFjJBRGvsdwa5wwa7hjMfpsbnWqcb0hYtQjXCgqlPs=.ad91f74c-c5c6-4ceb-aca2-ceabc5c3ca92@github.com>

On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make memory session a pure lifetime abstraction

src/java.base/share/classes/java/lang/foreign/MemorySession.java line 83:

> 81:  * MemorySegment segment = MemorySegment.allocateNative(100, MemorySession.implicit());
> 82:  * ...
> 83:  * segment = null; // the segment session is unreacheable here and becomes available for implicit close

Typo:
Suggestion:

 * segment = null; // the segment session is unreachable here and becomes available for implicit close

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

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

From jvernee at openjdk.org  Mon Nov  7 20:09:27 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 7 Nov 2022 20:09:27 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v5]
In-Reply-To: <7ZPsmtKqqOeItVnPztGyLhwuHi5Q9WsGI8SYzGkyL8Q=.33d63f63-9cbb-42bd-8d81-6555ed3d67d2@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <nLGKXMEfHApyxseQFp882Q-QXNxbkWcChh2Yv1COKG4=.70ef8fea-423b-4034-ad6e-026f2164f3c4@github.com>
 <7ZPsmtKqqOeItVnPztGyLhwuHi5Q9WsGI8SYzGkyL8Q=.33d63f63-9cbb-42bd-8d81-6555ed3d67d2@github.com>
Message-ID: <dPN_w9M_H0fIYJxhMN_-wbSWaxh3BeKsczT6N589Eeo=.36df4534-d66a-4b48-a9af-cd6cd1627f9c@github.com>

On Mon, 7 Nov 2022 14:59:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Bring windows CallArranger in sync with panama repo
>
> I have incorporated additional API changes, described in this document:
> http://cr.openjdk.java.net/~mcimadamore/panama/session_arenas.html
> 
> The main change is that `MemorySession` is now a pure lifetime abstraction and no longer implements `AutoCloseable`/`SegementAllocator`. Instead a new abstraction, called `Arena` should be used for deterministic deallocation use cases. This change allows several simplifications on the `MemorySession` API, as there's no more need to support non-closeable views.

@mcimadamore looks like your latest merge also undid the changes from you `b98febf` commit again

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

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

From dfuchs at openjdk.org  Mon Nov  7 20:14:46 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Nov 2022 20:14:46 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v8]
In-Reply-To: <8cBPylmbjzrUbBKkMHv9uT9hVhVWMOjoO3yrgoE98Qw=.a4073de6-6dc2-4b96-a36c-4c9aaa04eab9@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <8cBPylmbjzrUbBKkMHv9uT9hVhVWMOjoO3yrgoE98Qw=.a4073de6-6dc2-4b96-a36c-4c9aaa04eab9@github.com>
Message-ID: <S3bMkOhm9iupvAtO2dwGbehmtwm_QvbK8oiKrOXqVZU=.f5b6a1cd-08b2-476f-b910-bcb69fbd67ef@github.com>

On Mon, 7 Nov 2022 16:28:11 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed dupe line
>  - refactoring and cleanup

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 60:

> 58:                 if (!testNoPUEBeforeConnection(dc, refuser, sel, i)) {
> 59:                     break;
> 60:                 }

Thanks for the refactoring. It does make the test much easier to read! But we can still go one bit further:
  1. we could have the method return true if the test was successful. That would make the method result easier to understand, and would avoid the negation in the if statement above, which would make it easier to read too!
  2. we could change the loop to run from `i = 1 ; i <= MAX_TRIES ; i++` - this way we could check whether the maximum number of attempts was reached within the loop by comparing `i == MAX_TRIES` without having to subtract 1.
  3. assuming the changes above, we should throw an AssertionError if i == MAX_TRIES and we haven't broken out of the loop yet. 
 
So that loop would turn into:

           for (int i = 1; i <= MAX_TRIES; i++) {
                if (testNoPUEBeforeConnection(dc, refuser, sel, i)) {
                    break; // test succeeded
                }
                assertNotEquals(i, MAX_TRIES, "testNoPUEBeforeConnection: too many retries");
           }


The two other loops could be modified in the same way.

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 68:

> 66:                 for (int i = 0; i < MAX_TRIES; i++) {
> 67:                     if (!testPUEOnConnect(dc, refuser, sel, i)) {
> 68:                         break;

See suggestion above (1 to MAX_TRIES inclusive, assertNoEquals)

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 79:

> 77:                 if (!testNoPUEAfterDisconnect(dc, refuser, sel, i)) {
> 78:                     break;
> 79:                 }

See suggestion above (1 to MAX_TRIES inclusive, assertNoEquals)

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 115:

> 113:             // our expected refuser port, cannot run just exit.
> 114:             DatagramChannel.open().bind(refuser).close();
> 115:             throw new RuntimeException("Unexpected wakeup");

Assuming the changes suggested above, we could simplify that into:

    boolean mayRetry = checkUnexpectedWakeup(sel.selectedKeys());
    boolean tooManyRetries = retryCount >= MAX_TRIES;
    sel.selectedKeys().clear();
    if (mayRetry && !tooManyRetries) {
        return false; // will retry
    } 
    // BindException will be thrown if another service is using
    // our expected refuser port, cannot run just exit.
    DatagramChannel.open().bind(refuser).close();
    throw new RuntimeException("Unexpected wakeup"); 
}
return true; // test succeeded

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 162:

> 160:             }
> 161:         }
> 162:         return false;

Assuming the changes suggested above that would become:

             boolean mayRetry = retryCount < MAX_TRIES;
             if (mayRetry) return false;
             throw new RuntimeException("PortUnreachableException not raised");
         } catch (PortUnreachableException pue) {
             System.out.println("Got expected PortUnreachableException " + pue);
         }
     }
     return true; // test succeeded

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 190:

> 188:             throw new RuntimeException("Unexpected wakeup after disconnect");
> 189:         }
> 190:         return false;

Assuming the changes suggested above that would become:


    boolean mayRetry = checkUnexpectedWakeup(sel.selectedKeys());
    boolean tooManyRetries = retryCount >= MAX_TRIES;
    sel.selectedKeys().clear();
    if (mayRetry && !tooManyRetries) {
        return false; // will retry
    } 
    throw new RuntimeException("Unexpected wakeup after disconnect");
}
return true;  // test succeeded

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

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

From psandoz at openjdk.org  Mon Nov  7 20:42:16 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 7 Nov 2022 20:42:16 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v6]
In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
Message-ID: <s0VwUTJOI32CbUYWoy1AYtkQbnVZSiv_Uym4vhRpOxU=.19a6337a-bd1f-4b76-b410-a7a00af9318a@github.com>

On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make memory session a pure lifetime abstraction

src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 329:

> 327:         /**
> 328:          * Returns an <em>unbounded</em> address layout with the same carrier, alignment constraint, name and order as this address layout,
> 329:          * but with the specified pointee layout. An unbounded address layouts allow raw addresses to be accessed

Suggestion:

         * but with the specified pointee layout. An unbounded address layout allow raw addresses to be accessed

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

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

From psandoz at openjdk.org  Mon Nov  7 20:46:37 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 7 Nov 2022 20:46:37 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v6]
In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
Message-ID: <aCCxXd7YNUNb9EATYXyOIr-yjkqpwtGU86TG7l-YTqM=.4af1d051-af69-4116-a760-57948ff9424e@github.com>

On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make memory session a pure lifetime abstraction

src/java.base/share/classes/java/lang/foreign/package-info.java line 103:

> 101:  * the memory session associated with the segment being accessed has not been closed prematurely.
> 102:  * We call this guarantee <em>temporal safety</em>. Together, spatial and temporal safety ensure that each memory access
> 103:  * operation either succeeds - and accesses a valid location of the region of memory backing the memory segment - or fails.

Suggestion:

 * operation either succeeds - and accesses a valid location within the region of memory backing the memory segment - or fails.

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

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

From brian.burkhalter at oracle.com  Tue Nov  8 02:47:52 2022
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 8 Nov 2022 02:47:52 +0000
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
Message-ID: <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>


On Nov 4, 2022, at 5:51 AM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:






I had a thought for some code to try this on but seem to get a number of build errors now.

http://mikehall.pairserver.com/errors10140.txt <http://mikehall.pairserver.com/errors10140.txt>

Using the GitHub Desktop app to change to pr/10140

-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221102/d5ad452a/attachment.htm>

You are using xcode 14 with sdk for macos Ventura hence having issues. that's orthogonal to this PR.

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

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

What was suggested as the error here - isn?t. For me this doesn?t build with the errors given in the link.

No problem for me building with

* Toolchain:      clang (clang/LLVM from Xcode 12.4)

on macOS Monterey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221108/cbe1abb2/attachment.htm>

From mik3hall at gmail.com  Tue Nov  8 07:31:41 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 8 Nov 2022 01:31:41 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
Message-ID: <30DCD26F-1492-43B0-B4A8-917105B6492C@gmail.com>



> On Nov 7, 2022, at 8:47 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> 
>> On Nov 4, 2022, at 5:51 AM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>> 
>> 
>>>> 
>>>> 
>>>> 
>>>> I had a thought for some code to try this on but seem to get a number of build errors now.
>>>> 
>>>> http://mikehall.pairserver.com/errors10140.txt <http://mikehall.pairserver.com/errors10140.txt> <http://mikehall.pairserver.com/errors10140.txt <http://mikehall.pairserver.com/errors10140.txt>>
>>>> 
>>>> Using the GitHub Desktop app to change to pr/10140
>>>> 
>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221102/d5ad452a/attachment.htm <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221102/d5ad452a/attachment.htm>>
>>> 
>>> You are using xcode 14 with sdk for macos Ventura hence having issues. that's orthogonal to this PR.
>>> 
>>> -------------
>>> 
>>> PR: https://git.openjdk.org/jdk/pull/10140 <https://git.openjdk.org/jdk/pull/10140>
>> What was suggested as the error here - isn?t. For me this doesn?t build with the errors given in the link. 
> 
> No problem for me building with
> 
> * Toolchain:      clang (clang/LLVM from Xcode 12.4)
> 
> on macOS Monterey.

I?m also Monterey. Some of the errors were javac ones as well which should eliminate Xcode so I?m not sure what is going on. I am now 14.1 Xcode since it basically made me upgrade the last time I tried to launch but wasn?t when I got the errors. Might look at it some more. Pretty new to building these so it could very well be something I messed up. I had got something about a git merge conflict that seemed to disappear on it?s own.
For now I have just been coding up a WatchService using the polling current one.  

*** Javac error

/Users/mjh/Documents/GitHub/jdk/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java:38: error: cannot find symbol
import com.sun.source.doctree.SpecTree;
                             ^
  symbol:   class SpecTree
  location: package com.sun.source.doctree
   ... (rest of output omitted)

*** A lot of sprintf deprecated related errors, also show I was MacOSX13.0.sdk at the time.

* For target hotspot_variant-server_tools_adlc_objs_adlparse.o:
/Users/mjh/Documents/GitHub/jdk/src/hotspot/share/adlc/adlparse.cpp:215:11: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
          sprintf(buf, "%s_%d", instr->_ident, match_rules_cnt++);
          ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
__deprecated_msg("This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
        #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221108/604a1435/attachment-0001.htm>

From mcimadamore at openjdk.org  Tue Nov  8 10:36:49 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Nov 2022 10:36:49 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v7]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <oDftcc-CmPklo43VUAFWL4Vu5xc4tmlu6CNTXfHyrHg=.ef6d5a1b-4baf-4608-9b83-1f08aef9561f@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

Maurizio Cimadamore has updated the pull request incrementally with seven additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/foreign/MemorySession.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemoryLayout.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update src/java.base/share/classes/java/lang/foreign/Arena.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update src/java.base/share/classes/java/lang/foreign/Arena.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Bring windows CallArranger in sync with panama repo (again)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/f04be0da..cc4ff582

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

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

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

From alanb at openjdk.org  Tue Nov  8 10:36:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Nov 2022 10:36:49 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v6]
In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
Message-ID: <XldjMSAe4YRggxFjq5SJYgm82U6cVC9wI_7XKcFK3YQ=.5caadfe1-250e-4c31-9da9-9c6243574177@github.com>

On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make memory session a pure lifetime abstraction

src/java.base/share/classes/java/lang/ModuleLayer.java line 331:

> 329:                  "enableNativeAccess");
> 330:              target.implAddEnableNativeAccess();
> 331:              return this;

ModuelLayer.enableNativeAccess looks fine, we iterated on that in panama-foreign/pull/729. I assume you'll add @since 20. Also you might want to check the alignment, it looks like the method is indented by 5 instead of the usual 4 spaces.

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

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

From mcimadamore at openjdk.org  Tue Nov  8 10:42:13 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Nov 2022 10:42:13 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v8]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <1i9WM9QJ9WZsXv_3ZCsHRBDpG65nehSUjtww0HHTYcw=.c53b9cc2-45c9-49d4-bedf-1de71bf86f99@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

 - Fix bad indent on ModuleLayer.Controller
 - Update src/java.base/share/classes/java/lang/foreign/package-info.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update src/java.base/share/classes/java/lang/foreign/ValueLayout.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/cc4ff582..afb36a95

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

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

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

From duke at openjdk.org  Tue Nov  8 11:12:32 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 8 Nov 2022 11:12:32 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v9]
In-Reply-To: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
Message-ID: <qW6SOT3GvjN_shq5D3lB9g5bTs7w7YREski8g46oN-k=.03c029cc-f37b-4399-a773-137a2244b8e6@github.com>

> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
> 
> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.

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

  further cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10851/files
  - new: https://git.openjdk.org/jdk/pull/10851/files/f60a412e..d4d7d937

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

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

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

From duke at openjdk.org  Tue Nov  8 11:12:33 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 8 Nov 2022 11:12:33 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v8]
In-Reply-To: <8cBPylmbjzrUbBKkMHv9uT9hVhVWMOjoO3yrgoE98Qw=.a4073de6-6dc2-4b96-a36c-4c9aaa04eab9@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <8cBPylmbjzrUbBKkMHv9uT9hVhVWMOjoO3yrgoE98Qw=.a4073de6-6dc2-4b96-a36c-4c9aaa04eab9@github.com>
Message-ID: <ewTDbLbtO4hWtueMvpy9L9d5mG_SvRaYht-DMBwC0BE=.d0977ec3-3e81-4f11-b8b5-738b619ee67e@github.com>

On Mon, 7 Nov 2022 16:28:11 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed dupe line
>  - refactoring and cleanup

Thanks for those suggestions, I've added them in

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

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

From alanb at openjdk.org  Tue Nov  8 11:27:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Nov 2022 11:27:03 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v8]
In-Reply-To: <1i9WM9QJ9WZsXv_3ZCsHRBDpG65nehSUjtww0HHTYcw=.c53b9cc2-45c9-49d4-bedf-1de71bf86f99@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <1i9WM9QJ9WZsXv_3ZCsHRBDpG65nehSUjtww0HHTYcw=.c53b9cc2-45c9-49d4-bedf-1de71bf86f99@github.com>
Message-ID: <JECSFKnrC7PxS6M48mhn35efimvKQ_C_iuK8SvXaWUE=.bfc0324b-4cec-4ad7-8afb-9a3dc403a332@github.com>

On Tue, 8 Nov 2022 10:42:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix bad indent on ModuleLayer.Controller
>  - Update src/java.base/share/classes/java/lang/foreign/package-info.java
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>  - Update src/java.base/share/classes/java/lang/foreign/ValueLayout.java
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

src/java.base/share/classes/java/lang/foreign/Arena.java line 34:

> 32:  * An arena allocates and manages the lifecycle of native segments.
> 33:  * <p>
> 34:  * An arena is a {@linkplain AutoCloseable closeable} segment allocator that has a {@link #session() memory session}.

Should this is link MemorySession or linkplan memory session ?

src/java.base/share/classes/java/lang/foreign/Arena.java line 98:

> 96:      * that memory session are also released.
> 97:      * @throws IllegalStateException if the session associated with this arena is not {@linkplain MemorySession#isAlive() alive}.
> 98:      * @throws WrongThreadException if this method is called from a thread other than the thread

Should this be qualified to say that when the session is confined, and thread is called from a thread other than the owner?

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

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

From mcimadamore at openjdk.org  Tue Nov  8 13:28:58 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Nov 2022 13:28:58 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v9]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <B1_b3U4qE-cnF0jtLHfpn2k5NWFj1jadMO6K3VTMJFk=.03e3366d-0920-4120-8878-92199c61950e@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Rework package-level javadoc for restricted methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/afb36a95..e2840232

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

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

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

From dfuchs at openjdk.org  Tue Nov  8 14:17:18 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 8 Nov 2022 14:17:18 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v9]
In-Reply-To: <qW6SOT3GvjN_shq5D3lB9g5bTs7w7YREski8g46oN-k=.03c029cc-f37b-4399-a773-137a2244b8e6@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <qW6SOT3GvjN_shq5D3lB9g5bTs7w7YREski8g46oN-k=.03c029cc-f37b-4399-a773-137a2244b8e6@github.com>
Message-ID: <2KDm7yqO4xWm1zo7kXidWKDJmtLzH5hvsafbo-4IBWE=.be31a862-e271-4986-9028-6ed5b9d25ac3@github.com>

On Tue, 8 Nov 2022 11:12:32 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   further cleanup

Good work! This is much nicer. Just one small comment and one idle thought...

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 38:

> 36: import java.util.Set;
> 37: 
> 38: import static jdk.test.lib.Asserts.assertNotEquals;

Ah! Darn. I wonder if we should convert the test to testng or junit instead, just for the purpose of using junit/testng assertions. It would avoid the need of linking to /test/lib too. Just some idle thought.
The other day Pavel and I were wondering if that Asserts class should be retired - given that we have them available in testng/junit now...

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 87:

> 85:                 assertNotEquals(i, MAX_TRIES, "testNoPUEAfterDisconnect: too many retries");
> 86:             }
> 87:         } catch (BindException e) {

Maybe we should actually log that:

    System.out.println("Skipping test: refuser port has been reused: " + e);

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

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

From duke at openjdk.org  Tue Nov  8 14:53:24 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 8 Nov 2022 14:53:24 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v9]
In-Reply-To: <2KDm7yqO4xWm1zo7kXidWKDJmtLzH5hvsafbo-4IBWE=.be31a862-e271-4986-9028-6ed5b9d25ac3@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <qW6SOT3GvjN_shq5D3lB9g5bTs7w7YREski8g46oN-k=.03c029cc-f37b-4399-a773-137a2244b8e6@github.com>
 <2KDm7yqO4xWm1zo7kXidWKDJmtLzH5hvsafbo-4IBWE=.be31a862-e271-4986-9028-6ed5b9d25ac3@github.com>
Message-ID: <TpfokFkk5oeIKhjGCPHgrk8hQZFvMC5s6IHQ641H2u8=.ef7bc574-6438-4f72-b79e-c114a7826c8d@github.com>

On Tue, 8 Nov 2022 14:12:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   further cleanup
>
> test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 38:
> 
>> 36: import java.util.Set;
>> 37: 
>> 38: import static jdk.test.lib.Asserts.assertNotEquals;
> 
> Ah! Darn. I wonder if we should convert the test to testng or junit instead, just for the purpose of using junit/testng assertions. It would avoid the need of linking to /test/lib too. Just some idle thought.
> The other day Pavel and I were wondering if that Asserts class should be retired - given that we have them available in testng/junit now...

I wouldn't be against changing it, At a glance using Junit is only around 10 lines of changes, though I'm not sure if theres any additional patterns I should follow in swapping it to junit beyond using `@Test` instead of a main method?

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

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

From duke at openjdk.org  Tue Nov  8 16:01:20 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 8 Nov 2022 16:01:20 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v9]
In-Reply-To: <TpfokFkk5oeIKhjGCPHgrk8hQZFvMC5s6IHQ641H2u8=.ef7bc574-6438-4f72-b79e-c114a7826c8d@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <qW6SOT3GvjN_shq5D3lB9g5bTs7w7YREski8g46oN-k=.03c029cc-f37b-4399-a773-137a2244b8e6@github.com>
 <2KDm7yqO4xWm1zo7kXidWKDJmtLzH5hvsafbo-4IBWE=.be31a862-e271-4986-9028-6ed5b9d25ac3@github.com>
 <TpfokFkk5oeIKhjGCPHgrk8hQZFvMC5s6IHQ641H2u8=.ef7bc574-6438-4f72-b79e-c114a7826c8d@github.com>
Message-ID: <AQNq4-emCYK4urJWOoPik05dZvAgqAoZ7JdFfJ7fYt4=.7cb6f9e2-8ad2-48f8-9cbb-2d6d7fdc53ea@github.com>

On Tue, 8 Nov 2022 14:51:15 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 38:
>> 
>>> 36: import java.util.Set;
>>> 37: 
>>> 38: import static jdk.test.lib.Asserts.assertNotEquals;
>> 
>> Ah! Darn. I wonder if we should convert the test to testng or junit instead, just for the purpose of using junit/testng assertions. It would avoid the need of linking to /test/lib too. Just some idle thought.
>> The other day Pavel and I were wondering if that Asserts class should be retired - given that we have them available in testng/junit now...
>
> I wouldn't be against changing it, At a glance using Junit is only around 10 lines of changes, though I'm not sure if theres any additional patterns I should follow in swapping it to junit beyond using `@Test` instead of a main method? (and of course changing imports and `@run`)

I made the change there and made sure the test was still working as intended

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

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

From duke at openjdk.org  Tue Nov  8 16:01:18 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 8 Nov 2022 16:01:18 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v10]
In-Reply-To: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
Message-ID: <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>

> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
> 
> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.

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

  Use Junit for tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10851/files
  - new: https://git.openjdk.org/jdk/pull/10851/files/d4d7d937..14eb5875

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

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

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

From dfuchs at openjdk.org  Tue Nov  8 16:04:37 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 8 Nov 2022 16:04:37 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v10]
In-Reply-To: <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
Message-ID: <0qth-upnEo5pIG2cbOlvzCUvgWLXDduEUwKxVHe34WE=.2710955c-1260-449b-ac54-5b320e6a6994@github.com>

On Tue, 8 Nov 2022 16:01:18 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Junit for tests

LGTM! Good job.

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

Marked as reviewed by dfuchs (Reviewer).

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

From jvernee at openjdk.org  Tue Nov  8 16:20:53 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Nov 2022 16:20:53 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v6]
In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com>
Message-ID: <mnL8CNN1hqmOuLXzz5ZZo-p-bPv__ghv-cedWvLKMTU=.d703a0d4-5649-4f2c-b179-c490d926d7a1@github.com>

On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make memory session a pure lifetime abstraction

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 157:

> 155:     public long mismatch(MemorySegment other) {
> 156:         Objects.requireNonNull(other);
> 157:         return MemorySegment.mismatch(this, 0, byteSize(), other, 0, other.byteSize());

Bit strange to see this calling back up to a method in the interface. Maybe this should just be a `default` method in `MemorySegment`?

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 163:

> 161:      * Mismatch over long lengths.
> 162:      */
> 163:     public static long vectorizedMismatchLargeForBytes(MemorySessionImpl aSession, MemorySessionImpl bSession,

Does this need to be `public`? Only seems to be referenced below.

src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 179:

> 177:     @ForceInline
> 178:     public static MemorySessionImpl toSessionImpl(MemorySession session) {
> 179:         return (MemorySessionImpl)session;

Maybe calls to this method should just be replaced with a cast.

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java line 136:

> 134:         long ptr = UNSAFE.allocateMemory(LAYOUT.byteSize());
> 135:         MemorySegment ms = MemorySegment.ofAddress(ptr, LAYOUT.byteSize(),
> 136:                 MemorySession.implicit(), () -> UNSAFE.freeMemory(ptr));

pre-existing, but it seems like this could just use `MemorySegment.allocateNative(LAYOUT, MemorySession.implicit())`?
Suggestion:

        MemorySegment base = MemorySegment.allocateNative(LAYOUT, MemorySession.implicit());


(and remove the dependency on `Unsafe` altogether)

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java line 142:

> 140:         VH_gr_offs.set(ms, 0);
> 141:         VH_vr_offs.set(ms, 0);
> 142:         return ms;

I suggest doing 
Suggestion:

        return ms.asSlice(0, 0);


To create an opaque segment, just like the `segment()` accessor does. Or maybe update the implementation of `SharedUtils.emptyVaList` to do this.

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java line 408:

> 406:     @Override
> 407:     public MemorySegment segment() {
> 408:         return segment.asSlice(0, 0);

A comment about what is happening here would be nice. (making sure the returned segment is opaque?)

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java line 176:

> 174:     @Override
> 175:     public MemorySegment segment() {
> 176:         return segment.asSlice(0, 0);

Same here.

src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java line 145:

> 143:         long ptr = U.allocateMemory(LAYOUT.byteSize());
> 144:         MemorySegment base = MemorySegment.ofAddress(ptr, LAYOUT.byteSize(),
> 145:                 MemorySession.implicit(), () -> U.freeMemory(ptr));

Same here: `MemorySegment base = MemorySegment.allocateNative(LAYOUT, MemorySession.implicit());`

src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java line 150:

> 148:         VH_overflow_arg_area.set(base, MemorySegment.NULL);
> 149:         VH_reg_save_area.set(base, MemorySegment.NULL);
> 150:         return base;

Suggestion:

        return base.asSlice(0, 0);

test/jdk/java/foreign/normalize/TestNormalize.java line 203:

> 201:     public static Object[][] bools() {
> 202:         return new Object[][]{
> 203:             { 0b01,          true  }, // zero least significant bit, but non-zero first byte

According to the comment this should actually be:
Suggestion:

            { 0b10,          true  }, // zero least significant bit, but non-zero first byte


Looks like I wrote this by mistake :(

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

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

From jvernee at openjdk.org  Tue Nov  8 16:20:51 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Nov 2022 16:20:51 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v9]
In-Reply-To: <B1_b3U4qE-cnF0jtLHfpn2k5NWFj1jadMO6K3VTMJFk=.03e3366d-0920-4120-8878-92199c61950e@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <B1_b3U4qE-cnF0jtLHfpn2k5NWFj1jadMO6K3VTMJFk=.03e3366d-0920-4120-8878-92199c61950e@github.com>
Message-ID: <c1qV9PAvdc0F_hMKotT9UDO7x6Qea9bKM9XwNy887fo=.c54d69df-8432-45fe-bbd1-5d9729c3bb32@github.com>

On Tue, 8 Nov 2022 13:28:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework package-level javadoc for restricted methods

Did a full review. Only some minor comments.

Also, please add attribution with `/contributor add @<user>` for the people that contributed. (I think you have to add yourself as well, if you do that).

src/java.base/share/classes/java/lang/foreign/GroupLayout.java line 57:

> 55: 
> 56:     @Override
> 57:     GroupLayout withName(String name);

It looks like this method, and `withBitAlignment` below have no javadoc? Does this need `inheritDoc`?

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

> 73:  * <ul>
> 74:  * <li>if {@code L} is a {@link ValueLayout} with carrier {@code E} then {@code C = E}; or</li>
> 75:  * <li>if {@code L} is a {@link GroupLayout}, then {@code C} is set to {@code MemorySegment.class}</li>

Now that we have `FunctionDescriptor::toMethodType` I think this paragraph could be simplified by just referencing that.

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

> 99:  * <ul>
> 100:  * <li>if {@code L} is a {@link ValueLayout} with carrier {@code E} then {@code C = E}; or</li>
> 101:  * <li>if {@code L} is a {@link GroupLayout}, then {@code C} is set to {@code MemorySegment.class}</li>

Same here. This is covered by the doc of `FunctionDescriptor::toMethodType`.

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

> 117:  *     <li>The memory session of {@code A} is {@linkplain MemorySession#isAlive() alive}. Otherwise, the invocation throws
> 118:  *     {@link IllegalStateException};</li>
> 119:  *     <li>The invocation occurs in same thread as the one {@linkplain MemorySession#isOwnedBy(Thread) owning} the memory session of {@code R},

Suggestion:

 *     <li>The invocation occurs in same thread as the one {@linkplain MemorySession#isOwnedBy(Thread) owning} the memory session of {@code A},

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

> 119:  *     <li>The invocation occurs in same thread as the one {@linkplain MemorySession#isOwnedBy(Thread) owning} the memory session of {@code R},
> 120:  *     if said session is confined. Otherwise, the invocation throws {@link WrongThreadException}; and</li>
> 121:  *     <li>The memory session of {@code R} is <em>kept alive</em> (and cannot be closed) during the invocation.</li>

Suggestion:

 *     <li>The memory session of {@code A} is <em>kept alive</em> (and cannot be closed) during the invocation.</li>

src/java.base/share/classes/java/lang/foreign/StructLayout.java line 43:

> 41: 
> 42:     @Override
> 43:     StructLayout withName(String name);

Missing `inheritDoc`?

src/java.base/share/classes/java/lang/foreign/UnionLayout.java line 43:

> 41: 
> 42:     @Override
> 43:     UnionLayout withName(String name);

Missing `inheritDoc`?

src/java.base/share/classes/java/lang/foreign/VaList.java line 44:

> 42:  * Helper class to create and manipulate variable argument lists, similar in functionality to a C {@code va_list}.
> 43:  * <p>
> 44:  * A variable argument list segment can be created using the {@link #make(Consumer, MemorySession)} factory, as follows:

Suggestion:

 * A variable argument list can be created using the {@link #make(Consumer, MemorySession)} factory, as follows:

src/java.base/share/classes/java/lang/foreign/VaList.java line 50:

> 48:  *                                           .addVarg(C_DOUBLE, 3.8d));
> 49:  *}
> 50:  * Once created, clients can obtain the platform-dependent {@linkplain #segment() memory segment} associated a variable

Suggestion:

 * Once created, clients can obtain the platform-dependent {@linkplain #segment() memory segment} associated with a variable

src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 134:

> 132: 
> 133:     @Override
> 134:     ValueLayout withName(String name);

Missing `inheritDoc` here as well, and on other withers below.

src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 356:

> 354:      * Equivalent to the following code:
> 355:      * {@snippet lang=java :
> 356:      * ADDRESS.of(ByteOrder.nativeOrder())

This code doesn't look correct. It also looks like OfAddress layouts have their alignment set to the address size already, so the alignment adjustment here seems unnecessary as well.

src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 367:

> 365:      * Equivalent to the following code:
> 366:      * {@snippet lang=java :
> 367:      * JAVA_BYTE.of(ByteOrder.nativeOrder()).withBitAlignment(8);

Same here (and for the other snippets below), `OfByte` doesn't have an `of` method. This looks maybe like a regex-replace error.

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

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

From alanb at openjdk.org  Tue Nov  8 16:25:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Nov 2022 16:25:22 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v10]
In-Reply-To: <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
Message-ID: <6G6cWptQuppoG1ZUr7aRe9ECLzPAuSSWJ_aqs8vBVZo=.06d39947-021e-49d5-9b70-92205bbe026b@github.com>

On Tue, 8 Nov 2022 16:01:18 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Junit for tests

I see you've overhauled this test to be a JUnit test. If you are going that far then maybe it should go a bit further and have 3 test methods rather than having all tests in on test method. It just means setup/teardown is done 3 times, which is okay.

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

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

From mcimadamore at openjdk.org  Tue Nov  8 16:30:14 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Nov 2022 16:30:14 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v10]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <RdT4fePRQohvIzMlJ4rxv99nAE5ZKMqIbXFvfnBiCC8=.14e66173-56d0-4432-873f-4db2eb38335d@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

 - Revamp javadoc of Arena/MemorySession
   Rename MemorySession::isOwnedBy to MemorySession::isAccessibleBy
   Add Arena::isOwnedBy
 - Javadoc tweaks in MemorySession/Arena

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/e2840232..fd367106

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

  Stats: 311 lines in 10 files changed: 63 ins; 28 del; 220 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

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

From jvernee at openjdk.org  Tue Nov  8 16:36:34 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Nov 2022 16:36:34 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v10]
In-Reply-To: <RdT4fePRQohvIzMlJ4rxv99nAE5ZKMqIbXFvfnBiCC8=.14e66173-56d0-4432-873f-4db2eb38335d@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <RdT4fePRQohvIzMlJ4rxv99nAE5ZKMqIbXFvfnBiCC8=.14e66173-56d0-4432-873f-4db2eb38335d@github.com>
Message-ID: <MBVdyZl5z6iNj5IotZZhwL4KzXAMqG-tN2ijAsxaZM8=.78cbfbb9-198c-4767-88e3-f80e929e55c9@github.com>

On Tue, 8 Nov 2022 16:30:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revamp javadoc of Arena/MemorySession
>    Rename MemorySession::isOwnedBy to MemorySession::isAccessibleBy
>    Add Arena::isOwnedBy
>  - Javadoc tweaks in MemorySession/Arena

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

> 117:  *     <li>The memory session of {@code A} is {@linkplain MemorySession#isAlive() alive}. Otherwise, the invocation throws
> 118:  *     {@link IllegalStateException};</li>
> 119:  *     <li>The invocation occurs in same thread as the one {@linkplain MemorySession#isAccessibleBy(Thread) owning} the memory session of {@code R},

Suggestion:

 *     <li>The invocation occurs in same thread as the one {@linkplain MemorySession#isAccessibleBy(Thread) owning} the memory session of {@code A},

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

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

From dfuchs at openjdk.org  Tue Nov  8 16:48:35 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 8 Nov 2022 16:48:35 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v10]
In-Reply-To: <6G6cWptQuppoG1ZUr7aRe9ECLzPAuSSWJ_aqs8vBVZo=.06d39947-021e-49d5-9b70-92205bbe026b@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
 <6G6cWptQuppoG1ZUr7aRe9ECLzPAuSSWJ_aqs8vBVZo=.06d39947-021e-49d5-9b70-92205bbe026b@github.com>
Message-ID: <7x4HFKCJt93PvwMmlbgAIcEYTD9GWGIAA5_WGO6kFiw=.da3f57e1-ebd0-4a7e-b9be-f47a7f84088b@github.com>

On Tue, 8 Nov 2022 16:22:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I see you've overhauled this test to be a JUnit test. If you are going that far then maybe it should go a bit further and have 3 test methods rather than having all tests in on test method. It just means setup/teardown is done 3 times, which is okay.

Does it actually make sense? I thought the purpose of this test was to test before connecting, while connected, and after disconnecting. If we split into three different `@TEST` methods there's no telling in which order they will be executed.

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

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

From alanb at openjdk.org  Tue Nov  8 17:08:38 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Nov 2022 17:08:38 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v10]
In-Reply-To: <7x4HFKCJt93PvwMmlbgAIcEYTD9GWGIAA5_WGO6kFiw=.da3f57e1-ebd0-4a7e-b9be-f47a7f84088b@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
 <6G6cWptQuppoG1ZUr7aRe9ECLzPAuSSWJ_aqs8vBVZo=.06d39947-021e-49d5-9b70-92205bbe026b@github.com>
 <7x4HFKCJt93PvwMmlbgAIcEYTD9GWGIAA5_WGO6kFiw=.da3f57e1-ebd0-4a7e-b9be-f47a7f84088b@github.com>
Message-ID: <riqqXPP0EgpfKdLL4hgIWmwMnzA-ohkoPMrVc6GI4zQ=.ebcb4390-43bb-425b-9b1c-334ce997b116@github.com>

On Tue, 8 Nov 2022 16:45:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Does it actually make sense? I thought the purpose of this test was to test before connecting, while connected, and after disconnecting. If we split into three different `@TEST` methods there's no telling in which order they will be executed.

I think we created this test as part of work to get PUE on Windows.  Looking at it now, the "not connected" and the "connected" cases are two distinct scenarios. They could be separate test methods, each with their own setup and teardown. The execution order shouldn't matter as they will use different refusers.

The more advanced case is where you connect, then disconnect, and test that a PUE is not thrown.

I'll leave it you, I was just pointing out that it's one test method running three tests.

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

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

From mcimadamore at openjdk.org  Tue Nov  8 18:18:07 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Nov 2022 18:18:07 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v11]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <aX-NZP-MEh0lqwPI1IGvgSWWQwST66mnAevZVDMRWC4=.95e3dfe0-ec5a-4fe9-87bb-385eb7638ef8@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

 - Address review comments
 - More javadoc tweaks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/fd367106..bb39bef3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=09-10

  Stats: 190 lines in 21 files changed: 106 ins; 34 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

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

From jvernee at openjdk.org  Tue Nov  8 18:18:08 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Nov 2022 18:18:08 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v11]
In-Reply-To: <aX-NZP-MEh0lqwPI1IGvgSWWQwST66mnAevZVDMRWC4=.95e3dfe0-ec5a-4fe9-87bb-385eb7638ef8@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <aX-NZP-MEh0lqwPI1IGvgSWWQwST66mnAevZVDMRWC4=.95e3dfe0-ec5a-4fe9-87bb-385eb7638ef8@github.com>
Message-ID: <u4J7jObzndMfPVOmUQD6y33jBy6g3tyf9OL3IVNheEY=.7595f8ce-8ffd-4174-afc8-2a73d94d8b80@github.com>

On Tue, 8 Nov 2022 18:14:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>  - More javadoc tweaks

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/java/lang/foreign/MemorySession.java line 67:

> 65:  * cannot be easily determined. As shown in the example above, a memory session that is managed implicitly cannot end
> 66:  * if a program references to one or more segments associated with that session. This means that memory segments associated
> 67:  * with implicitly managed can be safely {@linkplain #isAccessibleBy(Thread) accessed} from multiple threads.

Suggestion:

 * with implicitly managed sessions can be safely {@linkplain #isAccessibleBy(Thread) accessed} from multiple threads.

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

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

From mcimadamore at openjdk.org  Tue Nov  8 18:28:40 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Nov 2022 18:28:40 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v12]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <3_cNn7GNS1M_3ouTex59atRvhCZX3_-cTeDtlGsLfuk=.4699a537-73b1-427a-a42c-a81ba874d658@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Update src/java.base/share/classes/java/lang/foreign/MemorySession.java
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/bb39bef3..fff83ca8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=10-11

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

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

From msheppar at openjdk.org  Tue Nov  8 19:57:36 2022
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 8 Nov 2022 19:57:36 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v10]
In-Reply-To: <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
Message-ID: <SPIHvQMJX2VKY9wNLTnuT-kBzSrqyZ29YIEXJUtpJYc=.7358574f-8d0b-4d0b-a1ea-49b47ecd79db@github.com>

On Tue, 8 Nov 2022 16:01:18 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Junit for tests

Using the setup strategy would be in keeping with junit idioms, but it is debatable if it is worth it here (i'm not advocating it).
If you were to use the junit setUp, then I think it would be more appropriately applied on the class 

    private static DatagramChannel dc;
    private static Selector sel;
    private static SocketAddress refuser;
    private static int port;
    

    @BeforeAll
    static void setupClass () {
    // test fixture resources setup
   }


    @AfterAll
    static void tearDownClass () {
       // close resources

   }

then your test fixtures become 
DatagramChannel dc, 
SocketAddress refuser, 
Selector sel,
int port
 which would reduce the parameters passed to each  test scenario method. But you'll have to handle any setup failures in the  setup method and barf if there are any problems, also. Where as what you have now  the test will just fail if any setup exceptions are encountered.

I think the test as one logical unit is best, because then the test has to handle the allocation of a ephemeral refuser port only once. But note that ephemeral refuser port is available for re-allocation by the OS for the duration of the test, and not just the initial test scenario where an OS re-allocation is tested. If the second connected scenario does not raise a PUE, then refuser port re-allocation could be a contributing factor, that is, the delivery of a datagram to an extant UDP end point. Again, it should be stated that this has not been the observed failure, but rather the unexpected wakeup in scenario 1 no PUE unconnected.

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

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

From mcimadamore at openjdk.org  Tue Nov  8 22:07:07 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Nov 2022 22:07:07 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v13]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <W6HEyQt73yjVqG0oFtAcGdHMvsW4Acfm-EQFZxaHYHA=.8d12840d-1956-4e93-893a-25256efe3d5b@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  More javadoc fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/fff83ca8..9be0c97b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=11-12

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

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

From mcimadamore at openjdk.org  Tue Nov  8 22:12:46 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Nov 2022 22:12:46 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v14]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <lEpO2Kc_JsL9bhFgf_zuibyNPm-O-zzgL9oJ0kxaDQY=.2027960f-2d7a-4ed6-b844-402a7bb478a2@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/9be0c97b..df29e6a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=12-13

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

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

From mik3hall at gmail.com  Wed Nov  9 01:33:26 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 8 Nov 2022 19:33:26 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
Message-ID: <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>



> On Nov 7, 2022, at 8:47 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
>> 
>> 
>> What was suggested as the error here - isn?t. For me this doesn?t build with the errors given in the link. 
> 
> No problem for me building with
> 
> * Toolchain:      clang (clang/LLVM from Xcode 12.4)
> 
> on macOS Monterey.

This got me on the right track.
I installed a early Xcode 13 and can build again.

* Toolchain:      clang (clang/LLVM from Xcode 13.1)

Apparently there are rather widespread problems building the jdk with either late 13 or 14 Xcode versions related at least mainly to the sprintf deprecation

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221108/4fa519d9/attachment.htm>

From brian.burkhalter at oracle.com  Wed Nov  9 03:47:44 2022
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 9 Nov 2022 03:47:44 +0000
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
 <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
Message-ID: <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>


On Nov 8, 2022, at 5:33 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:

What was suggested as the error here - isn?t. For me this doesn?t build with the errors given in the link.

No problem for me building with

* Toolchain:      clang (clang/LLVM from Xcode 12.4)

on macOS Monterey.

This got me on the right track.
I installed a early Xcode 13 and can build again.

Great! Glad it helped.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221109/9a1ee12c/attachment-0001.htm>

From alanb at openjdk.org  Wed Nov  9 09:20:35 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Nov 2022 09:20:35 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v14]
In-Reply-To: <lEpO2Kc_JsL9bhFgf_zuibyNPm-O-zzgL9oJ0kxaDQY=.2027960f-2d7a-4ed6-b844-402a7bb478a2@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <lEpO2Kc_JsL9bhFgf_zuibyNPm-O-zzgL9oJ0kxaDQY=.2027960f-2d7a-4ed6-b844-402a7bb478a2@github.com>
Message-ID: <l01fbF6hvDdtz__56Djm93FkoWC1l8XKv5Fyt_DaIiY=.346f3d23-9301-403c-8397-daf7e3c57622@github.com>

On Tue, 8 Nov 2022 22:12:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

src/java.base/share/classes/java/lang/foreign/Arena.java line 131:

> 129:      * @param thread the thread to be tested.
> 130:      */
> 131:     boolean isOwnedBy(Thread thread);

A shared Arena can be closed by any thread. Should a shared Arena be considered as being owned by all threads so that this method always returns true for a non-null thread? In the old API, a shared memory session has no owner so it was a bit clearer. I think my comment is mostly about the method name being about ownership, whereas the javadoc is about who can close.

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

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

From mcimadamore at openjdk.org  Wed Nov  9 11:00:33 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Nov 2022 11:00:33 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v14]
In-Reply-To: <l01fbF6hvDdtz__56Djm93FkoWC1l8XKv5Fyt_DaIiY=.346f3d23-9301-403c-8397-daf7e3c57622@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <lEpO2Kc_JsL9bhFgf_zuibyNPm-O-zzgL9oJ0kxaDQY=.2027960f-2d7a-4ed6-b844-402a7bb478a2@github.com>
 <l01fbF6hvDdtz__56Djm93FkoWC1l8XKv5Fyt_DaIiY=.346f3d23-9301-403c-8397-daf7e3c57622@github.com>
Message-ID: <ZfUc1DFmpM2mmWQBHOHf7AmZaO3wAnEkIvqdNBpjSkI=.3d59e62e-57f5-4d2b-9e50-49d7e06841a1@github.com>

On Wed, 9 Nov 2022 09:16:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> src/java.base/share/classes/java/lang/foreign/Arena.java line 131:
> 
>> 129:      * @param thread the thread to be tested.
>> 130:      */
>> 131:     boolean isOwnedBy(Thread thread);
> 
> A shared Arena can be closed by any thread. Should a shared Arena be considered as being owned by all threads so that this method always returns true for a non-null thread? In the old API, a shared memory session has no owner so it was a bit clearer. I think my comment is mostly about the method name being about ownership, whereas the javadoc is about who can close.

Very good point - all threads are owners.

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

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

From mcimadamore at openjdk.org  Wed Nov  9 11:42:47 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Nov 2022 11:42:47 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v15]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <NH0djbSdM731jDLBOtWZhzbMBZnJP4rLuAA3bqdo9eg=.d5e650a4-2e07-42d6-9361-147f2b578888@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Rename isOwnedBy -> isCloseableBy
  Fix minor typos
  Fix StrLenTest/RingAllocator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/df29e6a0..2d75f954

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=13-14

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

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

From alanb at openjdk.org  Wed Nov  9 12:05:35 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Nov 2022 12:05:35 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v14]
In-Reply-To: <lEpO2Kc_JsL9bhFgf_zuibyNPm-O-zzgL9oJ0kxaDQY=.2027960f-2d7a-4ed6-b844-402a7bb478a2@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <lEpO2Kc_JsL9bhFgf_zuibyNPm-O-zzgL9oJ0kxaDQY=.2027960f-2d7a-4ed6-b844-402a7bb478a2@github.com>
Message-ID: <s2MCZ3s24-cmdanKefZCacjxsI0k_1boT5dqXEb-q6k=.e91b667a-58c8-46ab-9dcf-50cfc8ca7f64@github.com>

On Tue, 8 Nov 2022 22:12:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

src/java.base/share/classes/java/lang/foreign/Arena.java line 125:

> 123:      */
> 124:     @Override
> 125:     void close();

I'm trying to understand how close interacts with whileAlive on its memory session. Does close throw or block when there is a critical action running? The javadoc doesn't say right now.

src/java.base/share/classes/java/lang/foreign/MemorySession.java line 43:

> 41:  * <p>
> 42:  * Conversely, a bounded memory session has a start and an end. Bounded memory sessions can be managed either
> 43:  * explicitly, (i.e. using an {@linkplain Arena arena}) or implicitly, by the garbage collector. When a bounded memory

A minor style thing here is that this should probably be "using an {@link Arena}" as you really mean the Arena. This helps a bit with the generate docs as it shows up currently as "arenaPREVIEW", if you see what I mean.

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

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

From mcimadamore at openjdk.org  Wed Nov  9 12:57:00 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Nov 2022 12:57:00 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v16]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <A7xNrmeNo7QAzd4Gk3jpF972G49QzYpAu1JzkBWvd-Q=.62dd27c9-39f6-4c4d-ae7c-1661324212d4@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

Maurizio Cimadamore has updated the pull request incrementally with four additional commits since the last revision:

 - Merge pull request #15 from minborg/test
   
   Add @apiNote to package-info
 - Add @apiNote to package-info
 - Merge pull request #16 from minborg/fix-tests2
   
   Fix failing tests
 - Fix failing tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/2d75f954..39521344

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=14-15

  Stats: 11 lines in 3 files changed: 4 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

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

From mcimadamore at openjdk.org  Wed Nov  9 13:24:54 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Nov 2022 13:24:54 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v17]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <Y6p315Q6Xv7ZWYDz0yMkyJxjYVxz6Iomu5phcti2KJE=.5f20042a-4d70-4dad-88ba-2883e1f8ab5f@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Tweak Arena::close javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/39521344..cd3fbe7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=15-16

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

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

From dfuchs at openjdk.org  Wed Nov  9 15:06:37 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 9 Nov 2022 15:06:37 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v10]
In-Reply-To: <SPIHvQMJX2VKY9wNLTnuT-kBzSrqyZ29YIEXJUtpJYc=.7358574f-8d0b-4d0b-a1ea-49b47ecd79db@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
 <SPIHvQMJX2VKY9wNLTnuT-kBzSrqyZ29YIEXJUtpJYc=.7358574f-8d0b-4d0b-a1ea-49b47ecd79db@github.com>
Message-ID: <W5UB_slblFailEWRjFA4voudXxSHWYFZNdkkFCOl5j4=.16174b8e-e515-4685-a96a-9c4cf4d02e0b@github.com>

On Tue, 8 Nov 2022 19:53:41 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> Using the setup strategy would be in keeping with junit idioms, but it is debatable if it is worth it here (i'm not advocating it).

Agreed. I don't think we should do this.

> If the second connected scenario does not raise a PUE, then refuser port re-allocation could be a contributing factor, that is, the delivery of a datagram to an extant UDP end point. 

Good observation. Maybe we should copy:

            // BindException will be thrown if another service is using
            // our expected refuser port, cannot run just exit.
            DatagramChannel.open().bind(refuser).close();

just before line 166.

If we really wanted to split into three tests  then each test should probably create its own refuser etc... 
That would mean cloning the test() method into 3 new method where:
1. the first one would return after the first loop.
2. the second one would remove the first loop and return after the second loop.
3. the third test would carry out the actions in the second loop without without performing any checks and without looping, and then would perform the third loop.

All in all I believe it's simpler to keep the single one test method that we have, even if it tests 3 scenarios - because at least we will be checking our assumption and print diagnosis information after each step along the way. It will be easier to reason about if it fails, I think.

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

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

From msheppar at openjdk.org  Wed Nov  9 15:33:17 2022
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 9 Nov 2022 15:33:17 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v10]
In-Reply-To: <W5UB_slblFailEWRjFA4voudXxSHWYFZNdkkFCOl5j4=.16174b8e-e515-4685-a96a-9c4cf4d02e0b@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
 <SPIHvQMJX2VKY9wNLTnuT-kBzSrqyZ29YIEXJUtpJYc=.7358574f-8d0b-4d0b-a1ea-49b47ecd79db@github.com>
 <W5UB_slblFailEWRjFA4voudXxSHWYFZNdkkFCOl5j4=.16174b8e-e515-4685-a96a-9c4cf4d02e0b@github.com>
Message-ID: <rypiAAOsr2RxPWUv0gTTm9oio5PUngJfQ7n-bVrYyg4=.4cf7f774-0439-469b-911c-91475ac4fd8d@github.com>

On Wed, 9 Nov 2022 15:00:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> All in all I believe it's simpler to keep the single one test method that we have, even if it tests 3 scenarios - because at least we will be checking our assumption and print diagnosis information after each step along the way. It will be easier to reason about if it fails, I think.

?

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

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

From duke at openjdk.org  Wed Nov  9 15:44:36 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 9 Nov 2022 15:44:36 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v10]
In-Reply-To: <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <O3JGLqBY5jPHHADsVPzO9uOxr5JBv67E2R2xYvlLB9I=.cf6e024c-4b24-4272-a3b7-e4b2796a0526@github.com>
Message-ID: <Ftur8kmYtGaGUkcyOA6urX9ReuMKHJeynYI-hCdR9JI=.f5493f7c-b45a-4195-a867-55d5576694fc@github.com>

On Tue, 8 Nov 2022 16:01:18 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Junit for tests

I'm in favor of keeping it to one test, though I can make that change to Line166 that was mentioned

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

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

From duke at openjdk.org  Wed Nov  9 18:38:28 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 9 Nov 2022 18:38:28 GMT
Subject: RFR: 8249693: java/nio/channels/FileChannel/FileExtensionAndMap.java
 uses @ignore w/o bug id
Message-ID: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>

Added a check that source and destination volumes have enough space to run the test.

This test will no longer be ignored.

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

Commit messages:
 - dummy commit
 - fixed line breaks, use FileStore::equals
 - updated copyright year
 - 8249693 Enabling test with check for available disk space.

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

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

From rhalade at openjdk.org  Wed Nov  9 18:38:29 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 9 Nov 2022 18:38:29 GMT
Subject: RFR: 8249693:
 java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id
In-Reply-To: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
References: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
Message-ID: <gTRaCKhFlrBHv5ZCn52zRQX8GlWFF3xAq-GPyq-Ov_g=.70f9fc3c-8427-4c71-98b7-43c13c953251@github.com>

On Mon, 7 Nov 2022 19:13:24 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Added a check that source and destination volumes have enough space to run the test.
> 
> This test will no longer be ignored.

Review title must match the JBS. See integration blocker "Title mismatch between PR and JBS for issue [JDK-8249693](https://bugs.openjdk.org/browse/JDK-8249693)"

Update this review title to "8249693: java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id"

test/jdk/java/nio/channels/FileChannel/FileExtensionAndMap.java line 22:

> 20:  * or visit www.oracle.com if you need additional information or have any
> 21:  * questions.
> 22:  */

please update the copyright year.

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

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

From duke at openjdk.org  Wed Nov  9 18:38:30 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 9 Nov 2022 18:38:30 GMT
Subject: RFR: 8249693:
 java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id
In-Reply-To: <gTRaCKhFlrBHv5ZCn52zRQX8GlWFF3xAq-GPyq-Ov_g=.70f9fc3c-8427-4c71-98b7-43c13c953251@github.com>
References: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
 <gTRaCKhFlrBHv5ZCn52zRQX8GlWFF3xAq-GPyq-Ov_g=.70f9fc3c-8427-4c71-98b7-43c13c953251@github.com>
Message-ID: <p3_uLrgv2_C5bUtVmgCZN2cno1VTRrppfqp7GEYvoYk=.4a049300-d428-41e9-b5de-bb21cf148639@github.com>

On Mon, 7 Nov 2022 19:18:06 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Added a check that source and destination volumes have enough space to run the test.
>> 
>> This test will no longer be ignored.
>
> test/jdk/java/nio/channels/FileChannel/FileExtensionAndMap.java line 22:
> 
>> 20:  * or visit www.oracle.com if you need additional information or have any
>> 21:  * questions.
>> 22:  */
> 
> please update the copyright year.

Updated

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

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

From alanb at openjdk.org  Wed Nov  9 18:38:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Nov 2022 18:38:31 GMT
Subject: RFR: 8249693:
 java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id
In-Reply-To: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
References: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
Message-ID: <Zqn_fyaKKyqNsnhRhdwy3Jze9CirZQ-bO-i31eD7XnA=.91a5fe1d-7b5c-41e1-b37c-fe89cb8e8dc3@github.com>

On Mon, 7 Nov 2022 19:13:24 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Added a check that source and destination volumes have enough space to run the test.
> 
> This test will no longer be ignored.

test/jdk/java/nio/channels/FileChannel/FileExtensionAndMap.java line 134:

> 132:         long totalDiskSpaceNeeded = FILESIZE * PARALLELISM;
> 133: 
> 134:         if (Files.getFileStore(tmpDir).name().equals(Files.getFileStore(destinationPath).name())) {

I think you should be using FileStore::equals rather than equality of the name here.

test/jdk/java/nio/channels/FileChannel/FileExtensionAndMap.java line 139:

> 137:             if (usableDiskSpace < totalDiskSpaceNeeded) {
> 138:                 throw new SkippedException("Insufficient disk space on " + TMPDIR + ". Test requires: " + totalDiskSpaceNeeded + ". Available on disk: " + usableDiskSpace);
> 139:             }

Can you break. these overfly long lines so that future side-by-side diffs are possible?

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

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

From duke at openjdk.org  Wed Nov  9 18:38:32 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 9 Nov 2022 18:38:32 GMT
Subject: RFR: 8249693:
 java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id
In-Reply-To: <Zqn_fyaKKyqNsnhRhdwy3Jze9CirZQ-bO-i31eD7XnA=.91a5fe1d-7b5c-41e1-b37c-fe89cb8e8dc3@github.com>
References: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
 <Zqn_fyaKKyqNsnhRhdwy3Jze9CirZQ-bO-i31eD7XnA=.91a5fe1d-7b5c-41e1-b37c-fe89cb8e8dc3@github.com>
Message-ID: <vUEidfmcagj_cQSEwokrUuSLj-htm9trJFi614HQqPs=.a55c1131-6a4d-4998-8481-efe52011fa5f@github.com>

On Mon, 7 Nov 2022 20:05:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Added a check that source and destination volumes have enough space to run the test.
>> 
>> This test will no longer be ignored.
>
> test/jdk/java/nio/channels/FileChannel/FileExtensionAndMap.java line 134:
> 
>> 132:         long totalDiskSpaceNeeded = FILESIZE * PARALLELISM;
>> 133: 
>> 134:         if (Files.getFileStore(tmpDir).name().equals(Files.getFileStore(destinationPath).name())) {
> 
> I think you should be using FileStore::equals rather than equality of the name here.

Done

> test/jdk/java/nio/channels/FileChannel/FileExtensionAndMap.java line 139:
> 
>> 137:             if (usableDiskSpace < totalDiskSpaceNeeded) {
>> 138:                 throw new SkippedException("Insufficient disk space on " + TMPDIR + ". Test requires: " + totalDiskSpaceNeeded + ". Available on disk: " + usableDiskSpace);
>> 139:             }
> 
> Can you break. these overfly long lines so that future side-by-side diffs are possible?

Sure, done.

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

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

From jjg at openjdk.org  Thu Nov 10 01:21:09 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 01:21:09 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
Message-ID: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>

Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.

"Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.

"Normalized" means...
* Use `https:` where possible (includes pretty much all cases)
* Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
* Point to the root page of a multi-page spec
* Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)

In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.

The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.

That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.

Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.

To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/

In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

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

Commit messages:
 - JDK-8296547: Add @spec tags to API

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

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

From mik3hall at gmail.com  Thu Nov 10 03:05:36 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 9 Nov 2022 21:05:36 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
 <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
 <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>
Message-ID: <4542163C-0BFF-47FC-BDBD-A43B82C3D29A@gmail.com>


I think someone may of mentioned benchmarks at some point. 

My thought on a watch service to try this on was monitoring the blockchain blocks for a full bitcoin client.

It doesn?t update all that often so not really a benchmark stress test. But a pretty easy one. Run both a polling and a FSEvents service.

java SimpleBTCWatcher
WatchService sun.nio.fs.PollingWatchService at 1b6d3586
Watching for events on /Volumes/BTC/Bitcoin/blocks
ENTRY_MODIFY occurred on blk03268.dat at 1668043049779 block access time 1668042238000 block modified time 1668043049610
ENTRY_MODIFY occurred on blk03268.dat at 1668043251780 block access time 1668043050000 block modified time 1668043251540
ENTRY_MODIFY occurred on blk03268.dat at 1668043609759 block access time 1668043608000 block modified time 1668043608650
ENTRY_MODIFY occurred on blk03268.dat at 1668043813761 block access time 1668043608000 block modified time 1668043813380
ENTRY_MODIFY occurred on blk03268.dat at 1668043943766 block access time 1668043814000 block modified time 1668043943550
ENTRY_MODIFY occurred on blk03268.dat at 1668044651774 block access time 1668043944000 block modified time 1668044651360
ENTRY_MODIFY occurred on blk03268.dat at 1668045843727 block access time 1668045842000 block modified time 1668045842250
ENTRY_MODIFY occurred on blk03268.dat at 1668045955806 block access time 1668045954000 block modified time 1668045954320
ENTRY_MODIFY occurred on blk03268.dat at 1668046521801 block access time 1668045954000 block modified time 1668046520890
ENTRY_MODIFY occurred on blk03268.dat at 1668047175806 block access time 1668047174000 block modified time 1668047174070
ENTRY_MODIFY occurred on blk03268.dat at 1668047485805 block access time 1668047174000 block modified time 1668047485660
ENTRY_MODIFY occurred on blk03268.dat at 1668047815828 block access time 1668047486000 block modified time 1668047814900

/Users/mjh/Documents/GitHub/jdk/build/*/images/jdk/bin/java -Dsun.nio.fs.MacOSXWatchService.use=true SimpleBTCWatcher
WatchService sun.nio.fs.MacOSXWatchService at 5c647e05
Watching for events on /Volumes/BTC/Bitcoin/blocks
ENTRY_MODIFY occurred on blk03268.dat at 1668043050347 block access time 1668042238000 block modified time 1668043049610
ENTRY_MODIFY occurred on blk03268.dat at 1668043252163 block access time 1668043050000 block modified time 1668043251540
ENTRY_MODIFY occurred on blk03268.dat at 1668043609299 block access time 1668043608000 block modified time 1668043608650
ENTRY_MODIFY occurred on blk03268.dat at 1668043814008 block access time 1668043608000 block modified time 1668043813380
ENTRY_MODIFY occurred on blk03268.dat at 1668043944009 block access time 1668043814000 block modified time 1668043943550
ENTRY_MODIFY occurred on blk03268.dat at 1668044652033 block access time 1668043944000 block modified time 1668044651360
ENTRY_MODIFY occurred on blk03268.dat at 1668045843305 block access time 1668044652000 block modified time 1668045842250
ENTRY_MODIFY occurred on blk03268.dat at 1668045954853 block access time 1668045842000 block modified time 1668045954320
ENTRY_MODIFY occurred on blk03268.dat at 1668046521441 block access time 1668045954000 block modified time 1668046520890
ENTRY_MODIFY occurred on blk03268.dat at 1668047175552 block access time 1668047174000 block modified time 1668047174070
ENTRY_MODIFY occurred on blk03268.dat at 1668047486484 block access time 1668047174000 block modified time 1668047485660
ENTRY_MODIFY occurred on blk03268.dat at 1668047815507 block access time 1668047486000 block modified time 1668047814900

The ?at? is System.currentTimeMillis. Polling often faster somewhat surprisingly? 

Running jconsole on both the only really significant difference I notice is gc.  For FSEvents?

Time: 	2022-11-09 20:45:24
Used: 	           155,387 kbytes
Committed: 	   266,240 kbytes
Max: 	 4,194,304 kbytes
GC time: 	 0.021 seconds on G1 Young Generation (2 collections)         
                 0.000 seconds on G1 Old Generation (0 collections) 

And for polling?

Time: 	2022-11-09 20:46:05
Used: 	          106,701 kbytes
Committed: 	   266,240 kbytes
Max: 	 4,194,304 kbytes
GC time: 	 0.081 seconds on G1 Young Generation (51 collections)         
                 0.000 seconds on G1 Old Generation (0 collections)

Polling gc?s considerably more often and takes relatively longer doing it. Still hundredths of a second. 
A more stressful  watch service might make this difference or other ones more significant.

Have any other platform implementations been benchmarked relative to polling?

From mike at hydraulic.software  Thu Nov 10 09:06:02 2022
From: mike at hydraulic.software (Mike Hearn)
Date: Thu, 10 Nov 2022 10:06:02 +0100
Subject: UNIX domain sockets bug on Windows
Message-ID: <CAGv+2bNfkcq1X_kHgahq=peMKwmZ2QtRaHf-2xTXFMxXwb1xuQ@mail.gmail.com>

Hi,

A customer reported that our app doesn't work on most but not all of
their Windows machines. We cannot reproduce it but the offending line
is simple:

   HttpClient.newBuilder().followRedirects(HttpClient.Redirect.NORMAL).build()

The stack trace shows clearly that this is a bug in either Windows or
Java. It attempts to open a UNIX domain socket as part of initializing
the sockets subsystem, and this goes wrong:

  Caused by: java.io.IOException: Unable to establish loopback connection
    at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:101)
    at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:67)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
    at java.base/sun.nio.ch.PipeImpl.<init>(PipeImpl.java:195)
    at java.base/sun.nio.ch.WEPollSelectorImpl.<init>(WEPollSelectorImpl.java:78)
    at java.base/sun.nio.ch.WEPollSelectorProvider.openSelector(WEPollSelectorProvider.java:33)
    at java.base/java.nio.channels.Selector.open(Selector.java:295)
    ... 11 more
  Caused by: java.net.SocketException: Invalid argument: connect
    at java.base/sun.nio.ch.UnixDomainSockets.connect0(Native Method)
    at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:148)
    at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:144)
    at java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:851)
    at java.base/java.nio.channels.SocketChannel.open(SocketChannel.java:285)
    at java.base/sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(PipeImpl.java:131)
    at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:83)
    ... 17 more

In July the change to use a UNIX domain socket in PipeImpl was rolled
back in JDK17 (JDK-8280233) due to the discovery of a race condition
in winsock that Microsoft apparently aren't going to fix any time soon
(or if they are, they won't backport it via Windows Update). But then
it's mentioned that the rollback is temporary and in JDK-8280944 the
selector wakeup code (which seems to be what's breaking here) is
switched to use domain sockets again, because the specific race in
winsock wouldn't hit that codepath,

This bug seems to be slightly different, as the failure isn't a hang
but rather always an exception. Therefore:

1. I am curious if anyone knows what might cause this specific error
with "Invalid argument: connect"? Is it possible that some Windows
users have UNIX domain sockets disabled by their admins, for example?
The machines that fail are joined to a managed Windows network.

2. From reading the code it appears that issues may have been found
during the initial implementation, because the pre-rollback code has a
"noUnixDomainSockets" flag that's set if there's a failure to open or
bind the server side of the socket, such that it will fall back to
TCP. But the exception I'm seeing comes from trying to open the client
side of the pipe (sc1 = SocketChannel.open(sa)), and there's no
fallback code there. Maybe this code needs to be made more robust
against UNIX domain sockets not working?

3. Overall it looks plausible that there are more bugs in Microsoft's
domain socket implementation which only appear on some machines and
not others. It's worth considering to not re-enable this code and
continue with the TCP based wakeup implementation, or at the very
least, provide a system property that allows the old codepath to be
used.

We bundle a lightly forked copy of JDK17 so my plan for now is to
include commit de739ff6 by Azul which backports the rollback to 17u,
and see if that works. But if anyone has better insight that would let
us unfork again, that would be appreciated.

thanks,
-mike

From Alan.Bateman at oracle.com  Thu Nov 10 09:53:57 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 10 Nov 2022 09:53:57 +0000
Subject: UNIX domain sockets bug on Windows
In-Reply-To: <CAGv+2bNfkcq1X_kHgahq=peMKwmZ2QtRaHf-2xTXFMxXwb1xuQ@mail.gmail.com>
References: <CAGv+2bNfkcq1X_kHgahq=peMKwmZ2QtRaHf-2xTXFMxXwb1xuQ@mail.gmail.com>
Message-ID: <57459407-d234-1be3-94e0-8b52826f1e86@oracle.com>


I haven't seen any recent issues reported in this area. It's possible 
this is related to something installed or some configuration on these 
systems. If something were fundamentally broken then I would expect we 
would have had many bug reports.

Do you know which releases of Windows this is? At one point we issues 
with 3rd party network stacks that allowed creating AF_UNIX sockets on 
Windows Server 2016 but didn't work correctly. This is why the code now 
checks that the transport protocol is from MS. I guess I would also try 
to find out if they have some security or other config on these systems. 
If you can do some debugging on their systems then it would help to see 
if there is a JDK issue or not.

-Alan

On 10/11/2022 09:06, Mike Hearn wrote:
> Hi,
>
> A customer reported that our app doesn't work on most but not all of
> their Windows machines. We cannot reproduce it but the offending line
> is simple:
>
>     HttpClient.newBuilder().followRedirects(HttpClient.Redirect.NORMAL).build()
>
> The stack trace shows clearly that this is a bug in either Windows or
> Java. It attempts to open a UNIX domain socket as part of initializing
> the sockets subsystem, and this goes wrong:
>
>    Caused by: java.io.IOException: Unable to establish loopback connection
>      at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:101)
>      at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:67)
>      at java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
>      at java.base/sun.nio.ch.PipeImpl.<init>(PipeImpl.java:195)
>      at java.base/sun.nio.ch.WEPollSelectorImpl.<init>(WEPollSelectorImpl.java:78)
>      at java.base/sun.nio.ch.WEPollSelectorProvider.openSelector(WEPollSelectorProvider.java:33)
>      at java.base/java.nio.channels.Selector.open(Selector.java:295)
>      ... 11 more
>    Caused by: java.net.SocketException: Invalid argument: connect
>      at java.base/sun.nio.ch.UnixDomainSockets.connect0(Native Method)
>      at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:148)
>      at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:144)
>      at java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:851)
>      at java.base/java.nio.channels.SocketChannel.open(SocketChannel.java:285)
>      at java.base/sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(PipeImpl.java:131)
>      at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:83)
>      ... 17 more
>
> In July the change to use a UNIX domain socket in PipeImpl was rolled
> back in JDK17 (JDK-8280233) due to the discovery of a race condition
> in winsock that Microsoft apparently aren't going to fix any time soon
> (or if they are, they won't backport it via Windows Update). But then
> it's mentioned that the rollback is temporary and in JDK-8280944 the
> selector wakeup code (which seems to be what's breaking here) is
> switched to use domain sockets again, because the specific race in
> winsock wouldn't hit that codepath,
>
> This bug seems to be slightly different, as the failure isn't a hang
> but rather always an exception. Therefore:
>
> 1. I am curious if anyone knows what might cause this specific error
> with "Invalid argument: connect"? Is it possible that some Windows
> users have UNIX domain sockets disabled by their admins, for example?
> The machines that fail are joined to a managed Windows network.
>
> 2. From reading the code it appears that issues may have been found
> during the initial implementation, because the pre-rollback code has a
> "noUnixDomainSockets" flag that's set if there's a failure to open or
> bind the server side of the socket, such that it will fall back to
> TCP. But the exception I'm seeing comes from trying to open the client
> side of the pipe (sc1 = SocketChannel.open(sa)), and there's no
> fallback code there. Maybe this code needs to be made more robust
> against UNIX domain sockets not working?
>
> 3. Overall it looks plausible that there are more bugs in Microsoft's
> domain socket implementation which only appear on some machines and
> not others. It's worth considering to not re-enable this code and
> continue with the TCP based wakeup implementation, or at the very
> least, provide a system property that allows the old codepath to be
> used.
>
> We bundle a lightly forked copy of JDK17 so my plan for now is to
> include commit de739ff6 by Azul which backports the rollback to 17u,
> and see if that works. But if anyone has better insight that would let
> us unfork again, that would be appreciated.
>
> thanks,
> -mike


From dfuchs at openjdk.org  Thu Nov 10 11:34:25 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Nov 2022 11:34:25 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Hi Jon,

When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:

http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html

External Specifications
    [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html)

You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing.
Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented.

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

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

From maxim.kartashev at jetbrains.com  Thu Nov 10 11:36:44 2022
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Thu, 10 Nov 2022 14:36:44 +0300
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <4542163C-0BFF-47FC-BDBD-A43B82C3D29A@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
 <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
 <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>
 <4542163C-0BFF-47FC-BDBD-A43B82C3D29A@gmail.com>
Message-ID: <CAG0Tb0hYvAabhJyxNyHTcG=LSpOKWe+pFeBHWDLciCN2sZ=oVQ@mail.gmail.com>

I benchmarked this implementation (well, the implementation this one is
based on, now it's become quite different) extensively. The main advantage
of FSEvents over polling was near-0 CPU usage when there were small number
of changes to the directory being watched, while polling naturally always
has some background job to do and its CPU usage heavily depends on refresh
speed (like 25% with SENSITIVITY_HIGH and modest rate of changes).

On Thu, Nov 10, 2022 at 6:22 AM Michael Hall <mik3hall at gmail.com> wrote:

>
> I think someone may of mentioned benchmarks at some point.
>
> My thought on a watch service to try this on was monitoring the blockchain
> blocks for a full bitcoin client.
>
> It doesn?t update all that often so not really a benchmark stress test.
> But a pretty easy one. Run both a polling and a FSEvents service.
>
> java SimpleBTCWatcher
> WatchService sun.nio.fs.PollingWatchService at 1b6d3586
> Watching for events on /Volumes/BTC/Bitcoin/blocks
> ENTRY_MODIFY occurred on blk03268.dat at 1668043049779 block access time
> 1668042238000 block modified time 1668043049610
> ENTRY_MODIFY occurred on blk03268.dat at 1668043251780 block access time
> 1668043050000 block modified time 1668043251540
> ENTRY_MODIFY occurred on blk03268.dat at 1668043609759 block access time
> 1668043608000 block modified time 1668043608650
> ENTRY_MODIFY occurred on blk03268.dat at 1668043813761 block access time
> 1668043608000 block modified time 1668043813380
> ENTRY_MODIFY occurred on blk03268.dat at 1668043943766 block access time
> 1668043814000 block modified time 1668043943550
> ENTRY_MODIFY occurred on blk03268.dat at 1668044651774 block access time
> 1668043944000 block modified time 1668044651360
> ENTRY_MODIFY occurred on blk03268.dat at 1668045843727 block access time
> 1668045842000 block modified time 1668045842250
> ENTRY_MODIFY occurred on blk03268.dat at 1668045955806 block access time
> 1668045954000 block modified time 1668045954320
> ENTRY_MODIFY occurred on blk03268.dat at 1668046521801 block access time
> 1668045954000 block modified time 1668046520890
> ENTRY_MODIFY occurred on blk03268.dat at 1668047175806 block access time
> 1668047174000 block modified time 1668047174070
> ENTRY_MODIFY occurred on blk03268.dat at 1668047485805 block access time
> 1668047174000 block modified time 1668047485660
> ENTRY_MODIFY occurred on blk03268.dat at 1668047815828 block access time
> 1668047486000 block modified time 1668047814900
>
> /Users/mjh/Documents/GitHub/jdk/build/*/images/jdk/bin/java
> -Dsun.nio.fs.MacOSXWatchService.use=true SimpleBTCWatcher
> WatchService sun.nio.fs.MacOSXWatchService at 5c647e05
> Watching for events on /Volumes/BTC/Bitcoin/blocks
> ENTRY_MODIFY occurred on blk03268.dat at 1668043050347 block access time
> 1668042238000 block modified time 1668043049610
> ENTRY_MODIFY occurred on blk03268.dat at 1668043252163 block access time
> 1668043050000 block modified time 1668043251540
> ENTRY_MODIFY occurred on blk03268.dat at 1668043609299 block access time
> 1668043608000 block modified time 1668043608650
> ENTRY_MODIFY occurred on blk03268.dat at 1668043814008 block access time
> 1668043608000 block modified time 1668043813380
> ENTRY_MODIFY occurred on blk03268.dat at 1668043944009 block access time
> 1668043814000 block modified time 1668043943550
> ENTRY_MODIFY occurred on blk03268.dat at 1668044652033 block access time
> 1668043944000 block modified time 1668044651360
> ENTRY_MODIFY occurred on blk03268.dat at 1668045843305 block access time
> 1668044652000 block modified time 1668045842250
> ENTRY_MODIFY occurred on blk03268.dat at 1668045954853 block access time
> 1668045842000 block modified time 1668045954320
> ENTRY_MODIFY occurred on blk03268.dat at 1668046521441 block access time
> 1668045954000 block modified time 1668046520890
> ENTRY_MODIFY occurred on blk03268.dat at 1668047175552 block access time
> 1668047174000 block modified time 1668047174070
> ENTRY_MODIFY occurred on blk03268.dat at 1668047486484 block access time
> 1668047174000 block modified time 1668047485660
> ENTRY_MODIFY occurred on blk03268.dat at 1668047815507 block access time
> 1668047486000 block modified time 1668047814900
>
> The ?at? is System.currentTimeMillis. Polling often faster somewhat
> surprisingly?
>
> Running jconsole on both the only really significant difference I notice
> is gc.  For FSEvents?
>
> Time:   2022-11-09 20:45:24
> Used:              155,387 kbytes
> Committed:         266,240 kbytes
> Max:     4,194,304 kbytes
> GC time:         0.021 seconds on G1 Young Generation (2 collections)
>
>                  0.000 seconds on G1 Old Generation (0 collections)
>
> And for polling?
>
> Time:   2022-11-09 20:46:05
> Used:             106,701 kbytes
> Committed:         266,240 kbytes
> Max:     4,194,304 kbytes
> GC time:         0.081 seconds on G1 Young Generation (51 collections)
>
>                  0.000 seconds on G1 Old Generation (0 collections)
>
> Polling gc?s considerably more often and takes relatively longer doing it.
> Still hundredths of a second.
> A more stressful  watch service might make this difference or other ones
> more significant.
>
> Have any other platform implementations been benchmarked relative to
> polling?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221110/cc8922af/attachment-0001.htm>

From duke at openjdk.org  Thu Nov 10 11:41:48 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Thu, 10 Nov 2022 11:41:48 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v11]
In-Reply-To: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
Message-ID: <7ny_8-8Ob6eU3djeA6x1kybP4K2uegtcYoLL-s8jN_U=.46004f91-8bd7-4f18-b249-c8cf94afda1c@github.com>

> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
> 
> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.

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

  added channel close

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10851/files
  - new: https://git.openjdk.org/jdk/pull/10851/files/14eb5875..4e26134e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10851&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10851&range=09-10

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

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

From alanb at openjdk.org  Thu Nov 10 11:49:21 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Nov 2022 11:49:21 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
Message-ID: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>

On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:

I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example:

http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html

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

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

From alanb at openjdk.org  Thu Nov 10 12:04:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Nov 2022 12:04:51 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

I'm just trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same will spec linked from "See also" and "External Specifications", e.g.
http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY
so the `@see` ref can be dropped.

In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication?

There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs.

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

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

From mik3hall at gmail.com  Thu Nov 10 12:10:14 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 10 Nov 2022 06:10:14 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <CAG0Tb0hYvAabhJyxNyHTcG=LSpOKWe+pFeBHWDLciCN2sZ=oVQ@mail.gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
 <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
 <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>
 <4542163C-0BFF-47FC-BDBD-A43B82C3D29A@gmail.com>
 <CAG0Tb0hYvAabhJyxNyHTcG=LSpOKWe+pFeBHWDLciCN2sZ=oVQ@mail.gmail.com>
Message-ID: <AD072DBE-0F7A-476C-A7E2-4CFEBBFF3F20@gmail.com>



> On Nov 10, 2022, at 5:36 AM, Maxim Kartashev <maxim.kartashev at jetbrains.com> wrote:
> 
> I benchmarked this implementation (well, the implementation this one is based on, now it's become quite different) extensively. The main advantage of FSEvents over polling was near-0 CPU usage when there were small number of changes to the directory being watched, while polling naturally always has some background job to do and its CPU usage heavily depends on refresh speed (like 25% with SENSITIVITY_HIGH and modest rate of changes).
> 

For this FSEvents did show near 0 cpu. Polling showed some but was still very low. It didn?t appear significant.
Again, other benchmarking that stressed different things might reveal other results. 




From msheppar at openjdk.org  Thu Nov 10 12:31:33 2022
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 10 Nov 2022 12:31:33 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v11]
In-Reply-To: <7ny_8-8Ob6eU3djeA6x1kybP4K2uegtcYoLL-s8jN_U=.46004f91-8bd7-4f18-b249-c8cf94afda1c@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <7ny_8-8Ob6eU3djeA6x1kybP4K2uegtcYoLL-s8jN_U=.46004f91-8bd7-4f18-b249-c8cf94afda1c@github.com>
Message-ID: <jeCiyj9tdScpCiAWFytVMXsiNEX-JcnAWZHMGZrLX4I=.b4cd151d-8b40-40b5-a0a6-b89d7b020063@github.com>

On Thu, 10 Nov 2022 11:41:48 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added channel close

good job

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

Marked as reviewed by msheppar (Reviewer).

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

From dfuchs at openjdk.org  Thu Nov 10 12:47:32 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Nov 2022 12:47:32 GMT
Subject: RFR: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup" [v11]
In-Reply-To: <7ny_8-8Ob6eU3djeA6x1kybP4K2uegtcYoLL-s8jN_U=.46004f91-8bd7-4f18-b249-c8cf94afda1c@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
 <7ny_8-8Ob6eU3djeA6x1kybP4K2uegtcYoLL-s8jN_U=.46004f91-8bd7-4f18-b249-c8cf94afda1c@github.com>
Message-ID: <mXoADds9KJYNG7CDjAYS-cYFJO5GAR_5nBgInA_kM0U=.750cf030-a849-4087-b855-829da33dabe6@github.com>

On Thu, 10 Nov 2022 11:41:48 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added channel close

Marked as reviewed by dfuchs (Reviewer).

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

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

From mike at hydraulic.software  Thu Nov 10 13:51:43 2022
From: mike at hydraulic.software (Mike Hearn)
Date: Thu, 10 Nov 2022 14:51:43 +0100
Subject: UNIX domain sockets bug on Windows
In-Reply-To: <57459407-d234-1be3-94e0-8b52826f1e86@oracle.com>
References: <CAGv+2bNfkcq1X_kHgahq=peMKwmZ2QtRaHf-2xTXFMxXwb1xuQ@mail.gmail.com>
 <57459407-d234-1be3-94e0-8b52826f1e86@oracle.com>
Message-ID: <CAGv+2bNwg02ZCUVhDd199dDZehgqXO+c1S75BhEY_caTnGTQBQ@mail.gmail.com>

Thanks. Yes, it's possible it's an issue created by e.g. security
software that's trying to intercept connections and doesn't understand
domain sockets. They reported that it happens on Windows 11 for many
people but the one person who used Windows 10 didn't see the issue.
I'm not sure how to interpret that, as presumably any AV scanner would
be the same, so I wonder if there's some interaction between Windows
11 and something else which isn't showing up more widely because it
requires some other condition to hold true first.

We can't debug on their systems unfortunately, nor reproduce the issue
locally. For now the stack trace is all we've got. I'll ask about
security software. I'm posting here in the hope that someone else
recognizes the failure, or if not, that this thread is useful to
future searchers.


On Thu, 10 Nov 2022 at 10:54, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>
> I haven't seen any recent issues reported in this area. It's possible
> this is related to something installed or some configuration on these
> systems. If something were fundamentally broken then I would expect we
> would have had many bug reports.
>
> Do you know which releases of Windows this is? At one point we issues
> with 3rd party network stacks that allowed creating AF_UNIX sockets on
> Windows Server 2016 but didn't work correctly. This is why the code now
> checks that the transport protocol is from MS. I guess I would also try
> to find out if they have some security or other config on these systems.
> If you can do some debugging on their systems then it would help to see
> if there is a JDK issue or not.
>
> -Alan
>
> On 10/11/2022 09:06, Mike Hearn wrote:
> > Hi,
> >
> > A customer reported that our app doesn't work on most but not all of
> > their Windows machines. We cannot reproduce it but the offending line
> > is simple:
> >
> >     HttpClient.newBuilder().followRedirects(HttpClient.Redirect.NORMAL).build()
> >
> > The stack trace shows clearly that this is a bug in either Windows or
> > Java. It attempts to open a UNIX domain socket as part of initializing
> > the sockets subsystem, and this goes wrong:
> >
> >    Caused by: java.io.IOException: Unable to establish loopback connection
> >      at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:101)
> >      at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:67)
> >      at java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
> >      at java.base/sun.nio.ch.PipeImpl.<init>(PipeImpl.java:195)
> >      at java.base/sun.nio.ch.WEPollSelectorImpl.<init>(WEPollSelectorImpl.java:78)
> >      at java.base/sun.nio.ch.WEPollSelectorProvider.openSelector(WEPollSelectorProvider.java:33)
> >      at java.base/java.nio.channels.Selector.open(Selector.java:295)
> >      ... 11 more
> >    Caused by: java.net.SocketException: Invalid argument: connect
> >      at java.base/sun.nio.ch.UnixDomainSockets.connect0(Native Method)
> >      at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:148)
> >      at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:144)
> >      at java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:851)
> >      at java.base/java.nio.channels.SocketChannel.open(SocketChannel.java:285)
> >      at java.base/sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(PipeImpl.java:131)
> >      at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:83)
> >      ... 17 more
> >
> > In July the change to use a UNIX domain socket in PipeImpl was rolled
> > back in JDK17 (JDK-8280233) due to the discovery of a race condition
> > in winsock that Microsoft apparently aren't going to fix any time soon
> > (or if they are, they won't backport it via Windows Update). But then
> > it's mentioned that the rollback is temporary and in JDK-8280944 the
> > selector wakeup code (which seems to be what's breaking here) is
> > switched to use domain sockets again, because the specific race in
> > winsock wouldn't hit that codepath,
> >
> > This bug seems to be slightly different, as the failure isn't a hang
> > but rather always an exception. Therefore:
> >
> > 1. I am curious if anyone knows what might cause this specific error
> > with "Invalid argument: connect"? Is it possible that some Windows
> > users have UNIX domain sockets disabled by their admins, for example?
> > The machines that fail are joined to a managed Windows network.
> >
> > 2. From reading the code it appears that issues may have been found
> > during the initial implementation, because the pre-rollback code has a
> > "noUnixDomainSockets" flag that's set if there's a failure to open or
> > bind the server side of the socket, such that it will fall back to
> > TCP. But the exception I'm seeing comes from trying to open the client
> > side of the pipe (sc1 = SocketChannel.open(sa)), and there's no
> > fallback code there. Maybe this code needs to be made more robust
> > against UNIX domain sockets not working?
> >
> > 3. Overall it looks plausible that there are more bugs in Microsoft's
> > domain socket implementation which only appear on some machines and
> > not others. It's worth considering to not re-enable this code and
> > continue with the TCP based wakeup implementation, or at the very
> > least, provide a system property that allows the old codepath to be
> > used.
> >
> > We bundle a lightly forked copy of JDK17 so my plan for now is to
> > include commit de739ff6 by Azul which backports the rollback to 17u,
> > and see if that works. But if anyone has better insight that would let
> > us unfork again, that would be appreciated.
> >
> > thanks,
> > -mike
>

From michael.x.mcmahon at oracle.com  Thu Nov 10 14:50:27 2022
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 10 Nov 2022 14:50:27 +0000
Subject: UNIX domain sockets bug on Windows
In-Reply-To: <CAGv+2bNwg02ZCUVhDd199dDZehgqXO+c1S75BhEY_caTnGTQBQ@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>
Message-ID: <247b5106-9d23-fc84-e602-ec0e75a5e2ca@oracle.com>

Considering that the PipeImpl is able to open and bind the server side 
of the pipe
and the step that fails is opening a client to the server this suggests
that security software is the most likely explanation and it is 
definitely not that
UNIX domain sockets are somehow disabled on the system. If that were
the case, then the initial creation of the server side would fail, and 
it would
fall back to TCP at that point.

- Michael.

On 10/11/2022 13:51, Mike Hearn wrote:

> Thanks. Yes, it's possible it's an issue created by e.g. security
> software that's trying to intercept connections and doesn't understand
> domain sockets. They reported that it happens on Windows 11 for many
> people but the one person who used Windows 10 didn't see the issue.
> I'm not sure how to interpret that, as presumably any AV scanner would
> be the same, so I wonder if there's some interaction between Windows
> 11 and something else which isn't showing up more widely because it
> requires some other condition to hold true first.
>
> We can't debug on their systems unfortunately, nor reproduce the issue
> locally. For now the stack trace is all we've got. I'll ask about
> security software. I'm posting here in the hope that someone else
> recognizes the failure, or if not, that this thread is useful to
> future searchers.
>
>
> On Thu, 10 Nov 2022 at 10:54, Alan Bateman<Alan.Bateman at oracle.com>  wrote:
>>
>> I haven't seen any recent issues reported in this area. It's possible
>> this is related to something installed or some configuration on these
>> systems. If something were fundamentally broken then I would expect we
>> would have had many bug reports.
>>
>> Do you know which releases of Windows this is? At one point we issues
>> with 3rd party network stacks that allowed creating AF_UNIX sockets on
>> Windows Server 2016 but didn't work correctly. This is why the code now
>> checks that the transport protocol is from MS. I guess I would also try
>> to find out if they have some security or other config on these systems.
>> If you can do some debugging on their systems then it would help to see
>> if there is a JDK issue or not.
>>
>> -Alan
>>
>> On 10/11/2022 09:06, Mike Hearn wrote:
>>> Hi,
>>>
>>> A customer reported that our app doesn't work on most but not all of
>>> their Windows machines. We cannot reproduce it but the offending line
>>> is simple:
>>>
>>>      HttpClient.newBuilder().followRedirects(HttpClient.Redirect.NORMAL).build()
>>>
>>> The stack trace shows clearly that this is a bug in either Windows or
>>> Java. It attempts to open a UNIX domain socket as part of initializing
>>> the sockets subsystem, and this goes wrong:
>>>
>>>     Caused by: java.io.IOException: Unable to establish loopback connection
>>>       at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:101)
>>>       at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:67)
>>>       at java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
>>>       at java.base/sun.nio.ch.PipeImpl.<init>(PipeImpl.java:195)
>>>       at java.base/sun.nio.ch.WEPollSelectorImpl.<init>(WEPollSelectorImpl.java:78)
>>>       at java.base/sun.nio.ch.WEPollSelectorProvider.openSelector(WEPollSelectorProvider.java:33)
>>>       at java.base/java.nio.channels.Selector.open(Selector.java:295)
>>>       ... 11 more
>>>     Caused by: java.net.SocketException: Invalid argument: connect
>>>       at java.base/sun.nio.ch.UnixDomainSockets.connect0(Native Method)
>>>       at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:148)
>>>       at java.base/sun.nio.ch.UnixDomainSockets.connect(UnixDomainSockets.java:144)
>>>       at java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:851)
>>>       at java.base/java.nio.channels.SocketChannel.open(SocketChannel.java:285)
>>>       at java.base/sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(PipeImpl.java:131)
>>>       at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:83)
>>>       ... 17 more
>>>
>>> In July the change to use a UNIX domain socket in PipeImpl was rolled
>>> back in JDK17 (JDK-8280233) due to the discovery of a race condition
>>> in winsock that Microsoft apparently aren't going to fix any time soon
>>> (or if they are, they won't backport it via Windows Update). But then
>>> it's mentioned that the rollback is temporary and in JDK-8280944 the
>>> selector wakeup code (which seems to be what's breaking here) is
>>> switched to use domain sockets again, because the specific race in
>>> winsock wouldn't hit that codepath,
>>>
>>> This bug seems to be slightly different, as the failure isn't a hang
>>> but rather always an exception. Therefore:
>>>
>>> 1. I am curious if anyone knows what might cause this specific error
>>> with "Invalid argument: connect"? Is it possible that some Windows
>>> users have UNIX domain sockets disabled by their admins, for example?
>>> The machines that fail are joined to a managed Windows network.
>>>
>>> 2. From reading the code it appears that issues may have been found
>>> during the initial implementation, because the pre-rollback code has a
>>> "noUnixDomainSockets" flag that's set if there's a failure to open or
>>> bind the server side of the socket, such that it will fall back to
>>> TCP. But the exception I'm seeing comes from trying to open the client
>>> side of the pipe (sc1 = SocketChannel.open(sa)), and there's no
>>> fallback code there. Maybe this code needs to be made more robust
>>> against UNIX domain sockets not working?
>>>
>>> 3. Overall it looks plausible that there are more bugs in Microsoft's
>>> domain socket implementation which only appear on some machines and
>>> not others. It's worth considering to not re-enable this code and
>>> continue with the TCP based wakeup implementation, or at the very
>>> least, provide a system property that allows the old codepath to be
>>> used.
>>>
>>> We bundle a lightly forked copy of JDK17 so my plan for now is to
>>> include commit de739ff6 by Azul which backports the rollback to 17u,
>>> and see if that works. But if anyone has better insight that would let
>>> us unfork again, that would be appreciated.
>>>
>>> thanks,
>>> -mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221110/ef7bddcd/attachment-0001.htm>

From weijun at openjdk.org  Thu Nov 10 16:24:26 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Nov 2022 16:24:26 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <YsQZKL7FoweoqYLwGrMarDb92lTrfeAWksgmD2tTktc=.424afc93-1eb4-42ef-8f1a-81a9db5e000e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

I see https://www.ietf.org/rfc/rfc0822.html. Should be https://www.ietf.org/rfc/rfc822.html

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

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

From duke at openjdk.org  Thu Nov 10 16:35:32 2022
From: duke at openjdk.org (AJ1062910)
Date: Thu, 10 Nov 2022 16:35:32 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

did you changed 420 files ?

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

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

From rhalade at openjdk.org  Thu Nov 10 21:09:26 2022
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 10 Nov 2022 21:09:26 GMT
Subject: RFR: 8249693:
 java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id
In-Reply-To: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
References: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
Message-ID: <0ZOOff2v7hEoFKSfscC9f7IHf5xdi3A4b5agR2aWR9U=.974833e0-5c0f-488d-bea8-8f2624dade3e@github.com>

On Mon, 7 Nov 2022 19:13:24 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Added a check that source and destination volumes have enough space to run the test.
> 
> This test will no longer be ignored.

Marked as reviewed by rhalade (Reviewer).

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

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

From duke at openjdk.org  Thu Nov 10 21:31:36 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 10 Nov 2022 21:31:36 GMT
Subject: RFR: 8249693:
 java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id
In-Reply-To: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
References: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
Message-ID: <kVLquLYh056iQKJeYzsUzosbXuE9A0-POgxW4Vd_MBU=.75f99b00-cd24-40c0-812d-91afc846a123@github.com>

On Mon, 7 Nov 2022 19:13:24 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Added a check that source and destination volumes have enough space to run the test.
> 
> This test will no longer be ignored.

@AlanBateman if you don't have other comments, would you please approve this? Thanks.

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

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

From mullan at openjdk.org  Thu Nov 10 21:34:30 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Nov 2022 21:34:30 GMT
Subject: RFR: JDK-8296547: Add @spec tags to API
In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
Message-ID: <9dD51N9kpu4MV5_oJ1e6lxsYLxnk6mG5mQeH_SAzWqA=.71dcec22-0ad2-41f2-89e3-8c9964db61cb@github.com>

On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> When referencing an RFC, it might be good to keep the RFC number in the text link.

+1.

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

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

From jjg at openjdk.org  Thu Nov 10 21:58:28 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 21:58:28 GMT
Subject: RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
Message-ID: <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>

On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Jon,
> 
> When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:
> 
> http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html
> 
> External Specifications [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html)
> 
> You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing. Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented.

On keeping RFC in the title, I'll go with the team preference. I note that not all spec authorities have such a well-defined naming/numbering scheme, so it does make the summary page a bit inconsistent. Also, the entries under "R" dominate the list, which may not be what you want.

On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec.

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

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

From jjg at openjdk.org  Thu Nov 10 22:03:32 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:03:32 GMT
Subject: RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com>
Message-ID: <jribbsj15UipAgtqxLmb156zaVOdJJU4zaukxrE-8Bg=.7b4f4219-ceb9-4173-a341-6d6fe2229ddd@github.com>

On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this:
> 
> I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example:
> 
> http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html

I can change the doclet to use a bulleted list when any spec titles contain a comma.

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

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

From jjg at openjdk.org  Thu Nov 10 22:11:30 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:11:30 GMT
Subject: RFR: JDK-8296546: Add @spec tags to API
In-Reply-To: <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <tPCblZfId85cQKio81tF2tewH6X-LqxttSXnNtzApVU=.2344dade-7a7c-4fd4-b472-c6229f1f730e@github.com>
Message-ID: <K4Z5QVATg9JlpZKp2HyIaHcMz_u24yhBOmw7RFkVmMo=.58dbad2c-e6cb-4fa5-857b-8c5bfb5007f0@github.com>

On Thu, 10 Nov 2022 12:01:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same spec will be linked from "See also" and "External Specifications", e.g. http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY so the `@see` ref can be dropped.
> 
> In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication?
> 
> There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs.

The utility I mentioned has the (optional) ability to remove `@see` links when the text of the link exactly matches that used by the `@spec` tag.  Unfortunately, the text is typically not exactly the same, and would require manual analysis to see if the `@see` tag can be removed.

When inline references are used, the wording is very rarely the primary title of the spec: it is more likely to be a word or phrase that makes sense in the context of the enclosing sentence.

_History: version 1 of this feature tried replacing inline links and `@see` tags with a bi-modal `@spec` tag. The results were "not good", especially in the generated external-specs page.  Version 2 used a side file to provide the definitive title for each spec, but that was deemed to be too much of a maintenance issue. This is version 3, in which we've eliminated the side-file in favor of duplicating the title in each `@spec` tag._

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

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

From jjg at openjdk.org  Thu Nov 10 22:19:26 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 10 Nov 2022 22:19:26 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <XJCprW4hLxs_RGOlh6hNULbDGp6knynwbUmwCiBJDik=.73780164-d49d-4251-b25e-35c152624567@github.com>
Message-ID: <Dt2pqnepgR8UMT5ypzYkvgJRKKxNg8K8m-vu3OdEFg4=.2c04027c-f939-4972-8eca-345fc6f923bc@github.com>

On Thu, 10 Nov 2022 16:33:09 GMT, AJ1062910 <duke at openjdk.org> wrote:

> did you changed 420 files ?

I ran a custom utility that edited these files, yes.

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

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

From naoto at openjdk.org  Thu Nov 10 23:55:34 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Nov 2022 23:55:34 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

src/java.base/share/classes/java/lang/Character.java line 172:

> 170:  * occur. For example, in a future release, synchronization may fail.
> 171:  *
> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0

This should probably be removed, as the original link (explaining `U+n` notation) is broken.

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

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

From psandoz at openjdk.org  Fri Nov 11 00:51:34 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 11 Nov 2022 00:51:34 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v17]
In-Reply-To: <Y6p315Q6Xv7ZWYDz0yMkyJxjYVxz6Iomu5phcti2KJE=.5f20042a-4d70-4dad-88ba-2883e1f8ab5f@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <Y6p315Q6Xv7ZWYDz0yMkyJxjYVxz6Iomu5phcti2KJE=.5f20042a-4d70-4dad-88ba-2883e1f8ab5f@github.com>
Message-ID: <g0K-MydrQsjl78yEthfG8UUNB87UYhiALFPKH55b2dQ=.5a700d31-e730-40b6-9986-6214082d0e70@github.com>

On Wed, 9 Nov 2022 13:24:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak Arena::close javadoc

src/java.base/share/classes/java/lang/foreign/Arena.java line 101:

> 99:      * @throws IllegalArgumentException if {@code bytesSize < 0}, {@code alignmentBytes <= 0}, or if {@code alignmentBytes}
> 100:      * is not a power of 2.
> 101:      * @throws IllegalStateException if the session associated with this arena is not {@linkplain MemorySession#isAlive() alive}.

Suggestion:

     * @throws IllegalStateException if arena's session is not {@linkplain MemorySession#isAlive() alive}.

src/java.base/share/classes/java/lang/foreign/Arena.java line 121:

> 119:      * segments associated with that memory session are also released.
> 120:      * @throws IllegalStateException if the session associated with this arena is not {@linkplain MemorySession#isAlive() alive}.
> 121:      * @throws IllegalStateException if this session is {@linkplain MemorySession#whileAlive(Runnable) kept alive} by another client.

Suggestion:

     * @throws IllegalStateException if the arena's session is not {@linkplain MemorySession#isAlive() alive}.
     * @throws IllegalStateException if the arena's session is {@linkplain MemorySession#whileAlive(Runnable) kept alive}.


Note i removed "by another client". I wanted to say "by another thread", but then there is the case of calling close from within the Runnable passed to whileAlive, so i wanted to say "by another caller". But, i think this can all be implied and we don't need to say anything.

src/java.base/share/classes/java/lang/foreign/MemorySession.java line 66:

> 64:  * is not critical, or in unstructured cases where the boundaries of the lifetime associated with a memory session
> 65:  * cannot be easily determined. As shown in the example above, a memory session that is managed implicitly cannot end
> 66:  * if a program references to one or more segments associated with that session. This means that memory segments associated

Suggestion:

 * if a program references one or more segments associated with that session. This means that memory segments associated

src/java.base/share/classes/java/lang/foreign/MemorySession.java line 89:

> 87: 
> 88:     /**
> 89:      * {@return {@code true} if the provided thread can access and/or obtain segments associated with this memory session}

Is the following accurate and more concise?
Suggestion:

     * {@return {@code true} if the provided thread can access and/or associate segments with this memory session}

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

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

From brian.burkhalter at oracle.com  Fri Nov 11 01:03:38 2022
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 11 Nov 2022 01:03:38 +0000
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <CAG0Tb0hYvAabhJyxNyHTcG=LSpOKWe+pFeBHWDLciCN2sZ=oVQ@mail.gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
 <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
 <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>
 <4542163C-0BFF-47FC-BDBD-A43B82C3D29A@gmail.com>
 <CAG0Tb0hYvAabhJyxNyHTcG=LSpOKWe+pFeBHWDLciCN2sZ=oVQ@mail.gmail.com>
Message-ID: <5C0E28DE-BAA0-4C47-9D83-9C8861EDB04A@oracle.com>

Near-0 CPU sounds good!

On Nov 10, 2022, at 3:36 AM, Maxim Kartashev <maxim.kartashev at jetbrains.com<mailto:maxim.kartashev at jetbrains.com>> wrote:

I benchmarked this implementation (well, the implementation this one is based on, now it's become quite different) extensively. The main advantage of FSEvents over polling was near-0 CPU usage when there were small number of changes to the directory being watched, while polling naturally always has some background job to do and its CPU usage heavily depends on refresh speed (like 25% with SENSITIVITY_HIGH and modest rate of changes).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221111/436a23c6/attachment-0001.htm>

From mik3hall at gmail.com  Fri Nov 11 01:12:38 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 10 Nov 2022 19:12:38 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <5C0E28DE-BAA0-4C47-9D83-9C8861EDB04A@oracle.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
 <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
 <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>
 <4542163C-0BFF-47FC-BDBD-A43B82C3D29A@gmail.com>
 <CAG0Tb0hYvAabhJyxNyHTcG=LSpOKWe+pFeBHWDLciCN2sZ=oVQ@mail.gmail.com>
 <5C0E28DE-BAA0-4C47-9D83-9C8861EDB04A@oracle.com>
Message-ID: <19DB680A-DDC5-45C7-A4A0-2BEE1C4E3425@gmail.com>



> On Nov 10, 2022, at 7:03 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Near-0 CPU sounds good!
> 
>> On Nov 10, 2022, at 3:36 AM, Maxim Kartashev <maxim.kartashev at jetbrains.com <mailto:maxim.kartashev at jetbrains.com>> wrote:
>> 
>> I benchmarked this implementation (well, the implementation this one is based on, now it's become quite different) extensively. The main advantage of FSEvents over polling was near-0 CPU usage when there were small number of changes to the directory being watched, while polling naturally always has some background job to do and its CPU usage heavily depends on refresh speed (like 25% with SENSITIVITY_HIGH and modest rate of changes).

It did. Neither usage or difference seemed significant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221110/495c22b5/attachment.htm>

From mik3hall at gmail.com  Fri Nov 11 01:19:21 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 10 Nov 2022 19:19:21 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <19DB680A-DDC5-45C7-A4A0-2BEE1C4E3425@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
 <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
 <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>
 <4542163C-0BFF-47FC-BDBD-A43B82C3D29A@gmail.com>
 <CAG0Tb0hYvAabhJyxNyHTcG=LSpOKWe+pFeBHWDLciCN2sZ=oVQ@mail.gmail.com>
 <5C0E28DE-BAA0-4C47-9D83-9C8861EDB04A@oracle.com>
 <19DB680A-DDC5-45C7-A4A0-2BEE1C4E3425@gmail.com>
Message-ID: <69A01109-19E8-4D4F-8AE2-DF55885ECAC2@gmail.com>



> On Nov 10, 2022, at 7:12 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Nov 10, 2022, at 7:03 PM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>> 
>> Near-0 CPU sounds good!
>> 
>>> On Nov 10, 2022, at 3:36 AM, Maxim Kartashev <maxim.kartashev at jetbrains.com <mailto:maxim.kartashev at jetbrains.com>> wrote:
>>> 
>>> I benchmarked this implementation (well, the implementation this one is based on, now it's become quite different) extensively. The main advantage of FSEvents over polling was near-0 CPU usage when there were small number of changes to the directory being watched, while polling naturally always has some background job to do and its CPU usage heavily depends on refresh speed (like 25% with SENSITIVITY_HIGH and modest rate of changes).
> 
> It did. Neither usage or difference seemed significant.

Although Maxim saw some difference in his benchmarking. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221110/349ec5b2/attachment.htm>

From cjplummer at openjdk.org  Fri Nov 11 04:18:30 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Nov 2022 04:18:30 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <FVrTbaSxMtpBDeg9b-elYkMoCM_M72PLSAQGVplwe1Q=.44879b38-e84d-436d-a23c-43f2522acf9e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/Connection.java line 105:

> 103:      *          If the length of the packet (as indictaed by the first
> 104:      *          4 bytes) is less than 11 bytes, or an I/O error occurs.
> 105:      * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/com/sun/jdi/connect/spi/Connection.html#readPacket()

Within this javadoc page the jdwp-spec.html references are titled "JDWP Specification", but these `@spec` references are titled "Java Debug Wire Protocol". I suggest making them more consistent. There is one more case below and this same issue also applies to TransportService.java. Perhaps the title in jdwp-spec.html should be updated. I think "Java Debug Wire Protocol (JDWP) Specification" would be good.

src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java line 79:

> 77:  * target VM.
> 78:  *
> 79:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol

See above comment for Connection.java.

src/jdk.jdi/share/classes/module-info.java line 107:

> 105:  *
> 106:  *
> 107:  * @spec jpda/jpda.html Java Platform Debugger Architecture

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/module-summary.html

`@spec` and `@see` sections end up one right after the other with the same content, except the `@see` section has the preferred hyperlink title. Suggest you remove the `@see` section and also update `@spec` hyperlink title to include "(JPDA)", or update the actual title in the jpda.html doc so it includes "(JPDA)" in it and then rerun your tool.

src/jdk.jdwp.agent/share/classes/module-info.java line 30:

> 28:  *
> 29:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
> 30:  * @spec jdwp/jdwp-transport.html Java Debug Wire Protocol Transport Interface (jdwpTransport)

http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdwp.agent/module-summary.html

The end result here is not very clean. You have the same two specs being referred to just a few lines apart, and the hyperlink titles are not even close to be the same, even though the links are the same. Maybe the "@see" section should be removed.

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

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

From alanb at openjdk.org  Fri Nov 11 08:00:42 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 11 Nov 2022 08:00:42 GMT
Subject: RFR: 8249693:
 java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id
In-Reply-To: <kVLquLYh056iQKJeYzsUzosbXuE9A0-POgxW4Vd_MBU=.75f99b00-cd24-40c0-812d-91afc846a123@github.com>
References: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
 <kVLquLYh056iQKJeYzsUzosbXuE9A0-POgxW4Vd_MBU=.75f99b00-cd24-40c0-812d-91afc846a123@github.com>
Message-ID: <Y0AbqiM2kIVW3C2CR4dx9nzLJTp3wQNnGGkTmZr749Y=.47287d67-d8dd-4319-a32c-c63dc1e43cb0@github.com>

On Thu, 10 Nov 2022 21:29:21 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> @AlanBateman if you don't have other comments, would you please approve this? Thanks.

I don't have time right now to look at this test closely right but just to say that the test may need to restricted to 64-bit (sun.arch.data.model == "64") if it really needs a 4Gb heap.

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

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

From maxim.kartashev at jetbrains.com  Fri Nov 11 09:22:24 2022
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Fri, 11 Nov 2022 12:22:24 +0300
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <69A01109-19E8-4D4F-8AE2-DF55885ECAC2@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
 <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
 <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>
 <4542163C-0BFF-47FC-BDBD-A43B82C3D29A@gmail.com>
 <CAG0Tb0hYvAabhJyxNyHTcG=LSpOKWe+pFeBHWDLciCN2sZ=oVQ@mail.gmail.com>
 <5C0E28DE-BAA0-4C47-9D83-9C8861EDB04A@oracle.com>
 <19DB680A-DDC5-45C7-A4A0-2BEE1C4E3425@gmail.com>
 <69A01109-19E8-4D4F-8AE2-DF55885ECAC2@gmail.com>
Message-ID: <CAG0Tb0hyU0PUPphguqH6buKobB5yDg_Uzst5T8ZFkEFoWH7mDQ@mail.gmail.com>

I imagine it's hard to get anything above 0% when watching just one
directory, nor is it representative of the use case I'm interested in (a
source code tree). My experiment was with a recursive watch of 50K files in
6K directories, 19K modifications done (files modified, added, removed,
directories added) in 8 minutes. That generated ~17% sys, ~7% user (24% of
one CPU overall) with the polling watch service.

On Fri, Nov 11, 2022 at 4:19 AM Michael Hall <mik3hall at gmail.com> wrote:

>
>
> On Nov 10, 2022, at 7:12 PM, Michael Hall <mik3hall at gmail.com> wrote:
>
>
>
> On Nov 10, 2022, at 7:03 PM, Brian Burkhalter <brian.burkhalter at oracle.com>
> wrote:
>
> Near-0 CPU sounds good!
>
> On Nov 10, 2022, at 3:36 AM, Maxim Kartashev <
> maxim.kartashev at jetbrains.com> wrote:
>
> I benchmarked this implementation (well, the implementation this one is
> based on, now it's become quite different) extensively. The main advantage
> of FSEvents over polling was near-0 CPU usage when there were small number
> of changes to the directory being watched, while polling naturally always
> has some background job to do and its CPU usage heavily depends on refresh
> speed (like 25% with SENSITIVITY_HIGH and modest rate of changes).
>
>
> It did. Neither usage or difference seemed significant.
>
>
> Although Maxim saw some difference in his benchmarking.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221111/e351bbde/attachment.htm>

From dfuchs at openjdk.org  Fri Nov 11 10:29:33 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 10:29:33 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <IK8qxT9eKCn8-eo-6CbSTFrtP5zoT2bvhB9wtt6fXdU=.21cca827-3991-4e1b-b572-0c22f3e3779b@github.com>
 <OlCdmjYt_2iOSA1j3vu6qkObw0M4a8IIVypow0V63L4=.2e4340f5-f905-44d4-ac4c-05027a32a887@github.com>
Message-ID: <WspQupF8fnStNO87pH42-2xTdbEwWYmiAcWuG2m3PSQ=.2d639a08-534c-4e41-aef9-287e4ab11a54@github.com>

On Thu, 10 Nov 2022 21:56:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec.

It's not uncommon for a newer version of a RFC to change its number but keep its title. I see that the links in the class level API documentation both have the RFC number in their link text. Somehow that was stripped by your tool - possibly because it tried to extract some meta information from the linked page itself?

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

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

From lancea at openjdk.org  Fri Nov 11 11:49:32 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 11 Nov 2022 11:49:32 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Hi Jon,

I only looked at the jar specific updates but there is some duplication leftovers.

It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs

src/java.base/share/classes/java/util/jar/Attributes.java line 58:

> 56:  * order that keys were inserted into the map, as with {@link LinkedHashMap}.
> 57:  *
> 58:  * @spec jar/jar.html JAR File Specification

Line 52 should be removed

src/java.base/share/classes/java/util/jar/Attributes.java line 450:

> 448:      * <a href="{@docRoot}/../specs/jar/jar.html">JAR File Specification</a>
> 449:      * for more information about valid attribute names and values.
> 450:      * @spec jar/jar.html JAR File Specification

Line 448 should be removed

src/java.base/share/classes/java/util/jar/Manifest.java line 47:

> 45:  * Manifest format specification</a>.
> 46:  *
> 47:  * @spec jar/jar.html JAR File Specification

Line 44 should be removed

src/java.base/share/classes/java/util/jar/package-info.java line 47:

> 45:  * </ul>
> 46:  *
> 47:  * @spec jar/jar.html JAR File Specification

Line 43 should be removed

src/java.base/share/classes/java/util/zip/package-info.java line 75:

> 73:  * </ul>
> 74:  *
> 75:  * @spec https://www.ietf.org/rfc/rfc1951.html DEFLATE Compressed Data Format Specification version 1.3

The above references should be removed as they duplicate the` @spec` tags

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

Changes requested by lancea (Reviewer).

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

From duke at openjdk.org  Fri Nov 11 12:00:16 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Fri, 11 Nov 2022 12:00:16 GMT
Subject: Integrated: 8293696:
 java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with
 "Unexpected wakeup"
In-Reply-To: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
References: <gWdM8VdIGnLIHfS036w4_9WA3lPsZOW9ajosjE3OwXM=.0478336a-6f0a-4f57-8eb4-85e4f366aa91@github.com>
Message-ID: <7-O3snymxHOWwbZt82OtQQ4B6UUmDSh5WFMs7Z5GCM0=.e542f96c-aab8-4799-a6fd-a138398d7381@github.com>

On Tue, 25 Oct 2022 12:35:15 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
> 
> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.

This pull request has now been integrated.

Changeset: fdabd379
Author:    Darragh Clarke <Darragh.clarke at oracle.com>
Committer: Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fdabd3796098c0ef0f528847da2cd98256443877
Stats:     188 lines in 1 file changed: 160 ins; 11 del; 17 mod

8293696: java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with "Unexpected wakeup"

Reviewed-by: dfuchs, msheppar

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

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

From dfuchs at openjdk.org  Fri Nov 11 12:01:42 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Nov 2022 12:01:42 GMT
Subject: RFR: 8296546: Add @spec tags to API
In-Reply-To: <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <F-0E4V_S1Ae3PQi6zKNhb6IQ7uRYrEDCuMi8nydqjiM=.e84f95c4-d35a-44ad-a3c4-d5a81eff72ae@github.com>
Message-ID: <siwyjzUschdL9bJ_M4fdQDfY59oCJ0aAZGwncWho3cM=.8fd36fb3-4f95-4f55-a353-d15df9e4078f@github.com>

On Fri, 11 Nov 2022 11:45:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs

Leaving out the non-public and non-exported classes would also reduce the PR size.

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

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

From mik3hall at gmail.com  Fri Nov 11 12:22:19 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 11 Nov 2022 06:22:19 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <CAG0Tb0hyU0PUPphguqH6buKobB5yDg_Uzst5T8ZFkEFoWH7mDQ@mail.gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
 <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
 <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>
 <4542163C-0BFF-47FC-BDBD-A43B82C3D29A@gmail.com>
 <CAG0Tb0hYvAabhJyxNyHTcG=LSpOKWe+pFeBHWDLciCN2sZ=oVQ@mail.gmail.com>
 <5C0E28DE-BAA0-4C47-9D83-9C8861EDB04A@oracle.com>
 <19DB680A-DDC5-45C7-A4A0-2BEE1C4E3425@gmail.com>
 <69A01109-19E8-4D4F-8AE2-DF55885ECAC2@gmail.com>
 <CAG0Tb0hyU0PUPphguqH6buKobB5yDg_Uzst5T8ZFkEFoWH7mDQ@mail.gmail.com>
Message-ID: <D2B4A215-988F-41CE-B8CC-92F3BDD7F6BE@gmail.com>



> On Nov 11, 2022, at 3:22 AM, Maxim Kartashev <maxim.kartashev at jetbrains.com> wrote:
> 
> I imagine it's hard to get anything above 0% when watching just one directory, nor is it representative of the use case I'm interested in (a source code tree). My experiment was with a recursive watch of 50K files in 6K directories, 19K modifications done (files modified, added, removed, directories added) in 8 minutes. That generated ~17% sys, ~7% user (24% of one CPU overall) with the polling watch service.
> 
> On Fri, Nov 11, 2022 at 4:19 AM Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
> 
> 
>> On Nov 10, 2022, at 7:12 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>> 
>> 
>>> On Nov 10, 2022, at 7:03 PM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>> 
>>> Near-0 CPU sounds good!
>>> 
>>>> On Nov 10, 2022, at 3:36 AM, Maxim Kartashev <maxim.kartashev at jetbrains.com <mailto:maxim.kartashev at jetbrains.com>> wrote:
>>>> 
>>>> I benchmarked this implementation (well, the implementation this one is based on, now it's become quite different) extensively. The main advantage of FSEvents over polling was near-0 CPU usage when there were small number of changes to the directory being watched, while polling naturally always has some background job to do and its CPU usage heavily depends on refresh speed (like 25% with SENSITIVITY_HIGH and modest rate of changes).
>> 
>> It did. Neither usage or difference seemed significant.
> 
> Although Maxim saw some difference in his benchmarking. 
> 

Much more a stress test than mine. I was seeing like 0% to 0.1% for FSEvents and .1% to .2% for polling. 
Did you get anything on memory and gc as well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221111/acfa7ac5/attachment.htm>

From maxim.kartashev at jetbrains.com  Fri Nov 11 13:48:00 2022
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Fri, 11 Nov 2022 16:48:00 +0300
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <D2B4A215-988F-41CE-B8CC-92F3BDD7F6BE@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
 <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
 <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>
 <4542163C-0BFF-47FC-BDBD-A43B82C3D29A@gmail.com>
 <CAG0Tb0hYvAabhJyxNyHTcG=LSpOKWe+pFeBHWDLciCN2sZ=oVQ@mail.gmail.com>
 <5C0E28DE-BAA0-4C47-9D83-9C8861EDB04A@oracle.com>
 <19DB680A-DDC5-45C7-A4A0-2BEE1C4E3425@gmail.com>
 <69A01109-19E8-4D4F-8AE2-DF55885ECAC2@gmail.com>
 <CAG0Tb0hyU0PUPphguqH6buKobB5yDg_Uzst5T8ZFkEFoWH7mDQ@mail.gmail.com>
 <D2B4A215-988F-41CE-B8CC-92F3BDD7F6BE@gmail.com>
Message-ID: <CAG0Tb0iqd2s5AtgBkL-4JcL4WNo_yKLw1mCqOwe7EmL3zfVw=g@mail.gmail.com>

> Did you get anything on memory and gc as well?
I did measure memory consumption and didn't measure gc; all in all, I don't
think it's representative as neither implementation allocates much in
response to outside events.

On Fri, Nov 11, 2022 at 3:22 PM Michael Hall <mik3hall at gmail.com> wrote:

>
>
> On Nov 11, 2022, at 3:22 AM, Maxim Kartashev <
> maxim.kartashev at jetbrains.com> wrote:
>
> I imagine it's hard to get anything above 0% when watching just one
> directory, nor is it representative of the use case I'm interested in (a
> source code tree). My experiment was with a recursive watch of 50K files in
> 6K directories, 19K modifications done (files modified, added, removed,
> directories added) in 8 minutes. That generated ~17% sys, ~7% user (24% of
> one CPU overall) with the polling watch service.
>
> On Fri, Nov 11, 2022 at 4:19 AM Michael Hall <mik3hall at gmail.com> wrote:
>
>>
>>
>> On Nov 10, 2022, at 7:12 PM, Michael Hall <mik3hall at gmail.com> wrote:
>>
>>
>>
>> On Nov 10, 2022, at 7:03 PM, Brian Burkhalter <
>> brian.burkhalter at oracle.com> wrote:
>>
>> Near-0 CPU sounds good!
>>
>> On Nov 10, 2022, at 3:36 AM, Maxim Kartashev <
>> maxim.kartashev at jetbrains.com> wrote:
>>
>> I benchmarked this implementation (well, the implementation this one is
>> based on, now it's become quite different) extensively. The main advantage
>> of FSEvents over polling was near-0 CPU usage when there were small number
>> of changes to the directory being watched, while polling naturally always
>> has some background job to do and its CPU usage heavily depends on refresh
>> speed (like 25% with SENSITIVITY_HIGH and modest rate of changes).
>>
>>
>> It did. Neither usage or difference seemed significant.
>>
>>
>> Although Maxim saw some difference in his benchmarking.
>>
>>
> Much more a stress test than mine. I was seeing like 0% to 0.1% for
> FSEvents and .1% to .2% for polling.
> Did you get anything on memory and gc as well?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221111/e90aa154/attachment-0001.htm>

From mik3hall at gmail.com  Fri Nov 11 14:22:54 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 11 Nov 2022 08:22:54 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v9]
In-Reply-To: <CAG0Tb0iqd2s5AtgBkL-4JcL4WNo_yKLw1mCqOwe7EmL3zfVw=g@mail.gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <tyYUQKVt-vd4ZRXvYUGPbeZGOcQzW7SK7oXqC2lEJx4=.c35df77e-0785-4e10-9b72-df9781092e04@github.com>
 <rbe8EWRLgGa7RJb65vfHfomyfPElVMM0IhH7parLhRI=.a5926a87-cc81-4efc-8cd0-5b979a0d49d2@github.com>
 <286F8E01-4A23-4F62-9186-9D1A0BA721B1@gmail.com>
 <ED4EC225-B6A2-462C-87D8-74596E7D0259@oracle.com>
 <4B5002E0-AAA5-43F1-9427-16A607ED8941@gmail.com>
 <B42E35EC-65FC-4E77-8EFC-E5E9C6C9ED0D@oracle.com>
 <4542163C-0BFF-47FC-BDBD-A43B82C3D29A@gmail.com>
 <CAG0Tb0hYvAabhJyxNyHTcG=LSpOKWe+pFeBHWDLciCN2sZ=oVQ@mail.gmail.com>
 <5C0E28DE-BAA0-4C47-9D83-9C8861EDB04A@oracle.com>
 <19DB680A-DDC5-45C7-A4A0-2BEE1C4E3425@gmail.com>
 <69A01109-19E8-4D4F-8AE2-DF55885ECAC2@gmail.com>
 <CAG0Tb0hyU0PUPphguqH6buKobB5yDg_Uzst5T8ZFkEFoWH7mDQ@mail.gmail.com>
 <D2B4A215-988F-41CE-B8CC-92F3BDD7F6BE@gmail.com>
 <CAG0Tb0iqd2s5AtgBkL-4JcL4WNo_yKLw1mCqOwe7EmL3zfVw=g@mail.gmail.com>
Message-ID: <D4E6C2DE-48F2-4C6A-A18A-B1B018573E8A@gmail.com>

>> 
> 
> Much more a stress test than mine. I was seeing like 0% to 0.1% for FSEvents and .1% to .2% for polling. 
> Did you get anything on memory and gc as well?

It didn?t seem to make all that much overall difference in memory for mine. But did seem to already have a considerable difference in gc behavior.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221111/f402fc1b/attachment.htm>

From alanb at openjdk.org  Sat Nov 12 16:38:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 12 Nov 2022 16:38:52 GMT
Subject: RFR: 8296797:
 java/nio/channels/vthread/BlockingChannelOps.testSocketChannelWriteAsyncClose
 failed with ClosedChannelException
Message-ID: <b41ySVVEn6mJf71oXN3eVQjxeXG1A6xRd8-nMjBTLZ0=.10cc10cb-37b2-4543-a8ad-54cf0934f718@github.com>

This is a test only change. BlockingChannelOps includes 4 tests that exercise async close/interrupt of a virtual thread that is blocked writing to a socket or pipe. The "setup" to have a thread to block indefinitely when writing is complicated when the underlying socket is non-blocking. It's very kernel dependent as to the behavior when the socket send buffer is full and there isn't anything reading from the other end of the connection. On macOS the socket becomes writable again after a 5s timeout, at which point a thread can write more bytes. On Windows the socket becomes writable again after a 1s. This behavior is nothing to do with virtual threads of course, its just the way that some kernels work with sockets configured non-blocking. For the test it means the methods that exercise async close/interrupt of a writer need to deal with the possibility that the writer thread may block more than once. If the writer thread blocks but awakes around the time of the async close/interrupt t
 hen its next call to write will close the channel and cause ClosedChannelException to be thrown. The 4 tests are changed to handle this so that they retry until they get the more specific exception expected for the scenario. The retry is rare, maybe 1 in 500 runs, and more efficient than changing the test to delay 5+ seconds to be sure that the writer thread is blocked.

While updating this test I noticed that some of the tests using Pipe don't close both the source and sink. Also the "delay XXX" comment in some tests is a bit misleading, and dates from when the test did use a delay/sleep.

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

Commit messages:
 - Initial commit

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

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

From chegar at openjdk.org  Sat Nov 12 17:33:12 2022
From: chegar at openjdk.org (Chris Hegarty)
Date: Sat, 12 Nov 2022 17:33:12 GMT
Subject: RFR: 8296797:
 java/nio/channels/vthread/BlockingChannelOps.testSocketChannelWriteAsyncClose
 failed with ClosedChannelException
In-Reply-To: <b41ySVVEn6mJf71oXN3eVQjxeXG1A6xRd8-nMjBTLZ0=.10cc10cb-37b2-4543-a8ad-54cf0934f718@github.com>
References: <b41ySVVEn6mJf71oXN3eVQjxeXG1A6xRd8-nMjBTLZ0=.10cc10cb-37b2-4543-a8ad-54cf0934f718@github.com>
Message-ID: <DtzqZWFt9epgbcF5l0GkIdLZrZAoe4Nd4_DPJDu-tQo=.8339faab-311e-4018-b8f7-0116c30c72cf@github.com>

On Fri, 11 Nov 2022 11:37:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change. BlockingChannelOps includes 4 tests that exercise async close/interrupt of a virtual thread that is blocked writing to a socket or pipe. The "setup" to have a thread to block indefinitely when writing is complicated when the underlying socket is non-blocking. It's very kernel dependent as to the behavior when the socket send buffer is full and there isn't anything reading from the other end of the connection. On macOS the socket becomes writable again after a 5s timeout, at which point a thread can write more bytes. On Windows the socket becomes writable again after a 1s. This behavior is nothing to do with virtual threads of course, its just the way that some kernels work with sockets configured non-blocking. For the test it means the methods that exercise async close/interrupt of a writer need to deal with the possibility that the writer thread may block more than once. If the writer thread blocks but awakes around the time of the async close/interrupt
  then its next call to write will close the channel and cause ClosedChannelException to be thrown. The 4 tests are changed to handle this so that they retry until they get the more specific exception expected for the scenario. The retry is rare, maybe 1 in 500 runs, and more efficient than changing the test to delay 5+ seconds to be sure that the writer thread is blocked.
> 
> While updating this test I noticed that some of the tests using Pipe don't close both the source and sink. Also the "delay XXX" comment in some tests is a bit misleading, and dates from when the test did use a delay/sleep.

LGTM

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

Marked as reviewed by chegar (Reviewer).

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

From jpai at openjdk.org  Sun Nov 13 05:35:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 13 Nov 2022 05:35:20 GMT
Subject: RFR: 8296797:
 java/nio/channels/vthread/BlockingChannelOps.testSocketChannelWriteAsyncClose
 failed with ClosedChannelException
In-Reply-To: <b41ySVVEn6mJf71oXN3eVQjxeXG1A6xRd8-nMjBTLZ0=.10cc10cb-37b2-4543-a8ad-54cf0934f718@github.com>
References: <b41ySVVEn6mJf71oXN3eVQjxeXG1A6xRd8-nMjBTLZ0=.10cc10cb-37b2-4543-a8ad-54cf0934f718@github.com>
Message-ID: <5TtWh__fauXOmPxGY7VPzNFj-c_56b8KhXOl2bry2Y8=.c84f3abb-fcd6-41d1-a170-aea8d3aa00b3@github.com>

On Fri, 11 Nov 2022 11:37:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change. BlockingChannelOps includes 4 tests that exercise async close/interrupt of a virtual thread that is blocked writing to a socket or pipe. The "setup" to have a thread to block indefinitely when writing is complicated when the underlying socket is non-blocking. It's very kernel dependent as to the behavior when the socket send buffer is full and there isn't anything reading from the other end of the connection. On macOS the socket becomes writable again after a 5s timeout, at which point a thread can write more bytes. On Windows the socket becomes writable again after a 1s. This behavior is nothing to do with virtual threads of course, its just the way that some kernels work with sockets configured non-blocking. For the test it means the methods that exercise async close/interrupt of a writer need to deal with the possibility that the writer thread may block more than once. If the writer thread blocks but awakes around the time of the async close/interrupt
  then its next call to write will close the channel and cause ClosedChannelException to be thrown. The 4 tests are changed to handle this so that they retry until they get the more specific exception expected for the scenario. The retry is rare, maybe 1 in 500 runs, and more efficient than changing the test to delay 5+ seconds to be sure that the writer thread is blocked.
> 
> While updating this test I noticed that some of the tests using Pipe don't close both the source and sink. Also the "delay XXX" comment in some tests is a bit misleading, and dates from when the test did use a delay/sleep.

Marked as reviewed by jpai (Reviewer).

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

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

From alanb at openjdk.org  Sun Nov 13 07:48:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 13 Nov 2022 07:48:06 GMT
Subject: Integrated: 8296797:
 java/nio/channels/vthread/BlockingChannelOps.testSocketChannelWriteAsyncClose
 failed with ClosedChannelException
In-Reply-To: <b41ySVVEn6mJf71oXN3eVQjxeXG1A6xRd8-nMjBTLZ0=.10cc10cb-37b2-4543-a8ad-54cf0934f718@github.com>
References: <b41ySVVEn6mJf71oXN3eVQjxeXG1A6xRd8-nMjBTLZ0=.10cc10cb-37b2-4543-a8ad-54cf0934f718@github.com>
Message-ID: <x7a7Os8HrS6WDh7OqxX0pRs97X95QrWU6JwOsHJubrA=.394371d3-9444-4673-875a-572d4d6965c8@github.com>

On Fri, 11 Nov 2022 11:37:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change. BlockingChannelOps includes 4 tests that exercise async close/interrupt of a virtual thread that is blocked writing to a socket or pipe. The "setup" to have a thread to block indefinitely when writing is complicated when the underlying socket is non-blocking. It's very kernel dependent as to the behavior when the socket send buffer is full and there isn't anything reading from the other end of the connection. On macOS the socket becomes writable again after a 5s timeout, at which point a thread can write more bytes. On Windows the socket becomes writable again after a 1s. This behavior is nothing to do with virtual threads of course, its just the way that some kernels work with sockets configured non-blocking. For the test it means the methods that exercise async close/interrupt of a writer need to deal with the possibility that the writer thread may block more than once. If the writer thread blocks but awakes around the time of the async close/interrupt
  then its next call to write will close the channel and cause ClosedChannelException to be thrown. The 4 tests are changed to handle this so that they retry until they get the more specific exception expected for the scenario. The retry is rare, maybe 1 in 500 runs, and more efficient than changing the test to delay 5+ seconds to be sure that the writer thread is blocked.
> 
> While updating this test I noticed that some of the tests using Pipe don't close both the source and sink. Also the "delay XXX" comment in some tests is a bit misleading, and dates from when the test did use a delay/sleep.

This pull request has now been integrated.

Changeset: 8eb90e2d
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8eb90e2d9c4ab5975f4301dbfdb0a6d9fa036af3
Stats:     117 lines in 1 file changed: 42 ins; 13 del; 62 mod

8296797: java/nio/channels/vthread/BlockingChannelOps.testSocketChannelWriteAsyncClose failed with ClosedChannelException

Reviewed-by: chegar, jpai

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

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

From alanb at openjdk.org  Sun Nov 13 15:31:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 13 Nov 2022 15:31:36 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
Message-ID: <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>

On Thu, 8 Sep 2022 07:21:07 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> In our CI system `test/jdk/java/nio/file/WatchService/Move.java` appears to time out consistently, although I have not seen it happen on my local machine.

I've been backed up with other things and finally getting to look at this more closely. For testing, I tried both release and debug builds across a range of macOS releases on both x64 and aarch64. Unfortunately there is a lot of timeouts and intermittent failures and across quite a range of macOS releases (from 10.15 to 12.2).

The most frequent failure seems to be the testOverflowEvent test in LotsOfEvents.  Here's an example failure:

----------System.out:(1/47)----------
Seed from RandomFactory = 1932318894124342221L
----------System.err:(12/655)----------
java.lang.RuntimeException: Key not signalled (unexpected)
	at LotsOfEvents.drainAndCheckOverflowEvents(LotsOfEvents.java:105)
	at LotsOfEvents.testOverflowEvent(LotsOfEvents.java:78)
	at LotsOfEvents.main(LotsOfEvents.java:51)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:1591)

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

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

From alanb at openjdk.org  Sun Nov 13 15:35:38 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 13 Nov 2022 15:35:38 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v8]
In-Reply-To: <fvqcSgHN-uY9Yn8QUGE0LeNM7XA2ZSMKA3EUZrcPSn0=.bb9502ad-022f-422a-9111-1f2595d7def9@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <h_gfCViVs9KuMeIhDCNzGD4N8wE57ArJM-T2EGyYzP4=.3c87b1de-2e58-44b5-85cb-3e66dd9dca22@github.com>
 <ay4oDKjwTh1VmbQlijzYRv7z3H0XSZB3TfiatnBZkDY=.42148f56-389b-4526-bf35-fc1789d57e73@github.com>
 <Nf4JhsYqnMvgXYoKLnBeeuRNdTlh_q8INM-rpyKxnQM=.71f14f0b-dfb9-4b9b-ad04-d69e5d2d5b4f@github.com>
 <8WHg8QPgBC2O2sYDXXHnL3Y2nS20dlzyUxRjr5r4Ctg=.2b07af8d-cc32-4f4f-bc6b-e043e6df66f7@github.com>
 <FQNZShhp0bmnGswXBPaZ8rYHSAgi1W3K5b6rVZWWlZM=.f1864e4f-5fd1-46c1-a5fc-67834fb19411@github.com>
 <ICUZ0-PGeM8QASztgXve5VGbs0ILVvClftlh9IRG_Zs=.5626c42e-4515-4def-b423-b29a57e4cca0@github.com>
 <fvqcSgHN-uY9Yn8QUGE0LeNM7XA2ZSMKA3EUZrcPSn0=.bb9502ad-022f-422a-9111-1f2595d7def9@github.com>
Message-ID: <damJwQy4xc5ZF7EAwdXZjAadaT9kw7fOFK4-eMiqdZA=.97919808-1445-4d11-a7e0-831280c6f752@github.com>

On Wed, 2 Nov 2022 06:25:03 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> @mkartashev I made some minor changes to the CSR. Was the property name previously agreed upon? I would tend to drop the `.use` from the end of it.
>
>> Was the property name previously agreed upon?
> 
> Nope. Please, rename as you see fit, I really have no preference nor do I have any experience in CSRs.

If we can get the new implementation stable then it might not be worth including the polling implementation in the macOS build. The make file that controls whether PollingWatchService is included or not is in make/modules/java.base/Java.gmk.

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

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

From aturbanov at openjdk.org  Sun Nov 13 16:55:27 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 13 Nov 2022 16:55:27 GMT
Subject: RFR: 8249693:
 java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id
In-Reply-To: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
References: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
Message-ID: <9H2tmCmaxtVYbfqxQMr4Wc48ujyvLVko1zWcbrYmWUM=.360a15f4-8ca9-4e15-ac90-15ac74a309c1@github.com>

On Mon, 7 Nov 2022 19:13:24 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Added a check that source and destination volumes have enough space to run the test.
> 
> This test will no longer be ignored.

test/jdk/java/nio/channels/FileChannel/FileExtensionAndMap.java line 146:

> 144:             for (Path p : List.of(destinationPath, tmpDir)) {
> 145:                 long usableDiskSpace = Files.getFileStore(p).getUsableSpace();
> 146:                 if(usableDiskSpace < totalDiskSpaceNeeded) {

Suggestion:

                if (usableDiskSpace < totalDiskSpaceNeeded) {

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

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

From mik3hall at gmail.com  Mon Nov 14 03:08:44 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 13 Nov 2022 21:08:44 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v8]
In-Reply-To: <damJwQy4xc5ZF7EAwdXZjAadaT9kw7fOFK4-eMiqdZA=.97919808-1445-4d11-a7e0-831280c6f752@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <h_gfCViVs9KuMeIhDCNzGD4N8wE57ArJM-T2EGyYzP4=.3c87b1de-2e58-44b5-85cb-3e66dd9dca22@github.com>
 <ay4oDKjwTh1VmbQlijzYRv7z3H0XSZB3TfiatnBZkDY=.42148f56-389b-4526-bf35-fc1789d57e73@github.com>
 <Nf4JhsYqnMvgXYoKLnBeeuRNdTlh_q8INM-rpyKxnQM=.71f14f0b-dfb9-4b9b-ad04-d69e5d2d5b4f@github.com>
 <8WHg8QPgBC2O2sYDXXHnL3Y2nS20dlzyUxRjr5r4Ctg=.2b07af8d-cc32-4f4f-bc6b-e043e6df66f7@github.com>
 <FQNZShhp0bmnGswXBPaZ8rYHSAgi1W3K5b6rVZWWlZM=.f1864e4f-5fd1-46c1-a5fc-67834fb19411@github.com>
 <ICUZ0-PGeM8QASztgXve5VGbs0ILVvClftlh9IRG_Zs=.5626c42e-4515-4def-b423-b29a57e4cca0@github.com>
 <fvqcSgHN-uY9Yn8QUGE0LeNM7XA2ZSMKA3EUZrcPSn0=.bb9502ad-022f-422a-9111-1f2595d7def9@github.com>
 <damJwQy4xc5ZF7EAwdXZjAadaT9kw7fOFK4-eMiqdZA=.97919808-1445-4d11-a7e0-831280c6f752@github.com>
Message-ID: <52956209-5A07-49F5-B32B-F603D6867C06@gmail.com>



> On Nov 13, 2022, at 9:35 AM, Alan Bateman <alanb at openjdk.org> wrote:
> 
> On Wed, 2 Nov 2022 06:25:03 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:
> 
>>> @mkartashev I made some minor changes to the CSR. Was the property name previously agreed upon? I would tend to drop the `.use` from the end of it.
>> 
>>> Was the property name previously agreed upon?
>> 
>> Nope. Please, rename as you see fit, I really have no preference nor do I have any experience in CSRs.
> 
> If we can get the new implementation stable then it might not be worth including the polling implementation in the macOS build. The make file that controls whether PollingWatchService is included or not is in make/modules/java.base/Java.gmk.
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/10140

This still doesn?t appear to show local errors for me. I ran a modified LotsOfEvents 5 times which should amount to actually 25 test runs including concurrently. Without an error.

    public static void main(String[] args) throws Exception {
		new LotsOfEvents().runTests();
    }

	private void runTests() {
		ExecutorService taskList
            = Executors.newFixedThreadPool(2);
  
        taskList.execute(new TestRunner(1));
        taskList.execute(new TestRunner(2));
        taskList.execute(new TestRunner(3));
        taskList.execute(new TestRunner(4));
        taskList.execute(new TestRunner(5));
        taskList.shutdown();		
	}

OS/X 12.6 Monterey
/Users/mjh/Documents/GitHub/jdk/build/*/images/jdk/bin/java -version    
openjdk version "20-internal" 2023-03-21
OpenJDK Runtime Environment (build 20-internal-adhoc.mjh.jdk)
OpenJDK 64-Bit Server VM (build 20-internal-adhoc.mjh.jdk, mixed mode, sharing)

Sample output?

/Users/mjh/Documents/GitHub/jdk/build/*/images/jdk/bin/java LotsOfEvents
Seed from RandomFactory = 6528454270926080835L
watcher sun.nio.fs.MacOSXWatchService at 6aa1966b class sun.nio.fs.MacOSXWatchService
watcher sun.nio.fs.MacOSXWatchService at 3ddb944c class sun.nio.fs.MacOSXWatchService
Polling retrieved 1 event(s)
Polling retrieved 1 event(s)
Polling retrieved 1 event(s)
Polling retrieved 1 event(s)
1 overflow elapsed 32644
2 overflow elapsed 32642

?
watcher sun.nio.fs.MacOSXWatchService at 4298fd66 class sun.nio.fs.MacOSXWatchService
Polling retrieved 1 event(s)
Polling retrieved 1 event(s)
5 overflow elapsed 32214
5queuing elapsed 25096



From duke at openjdk.org  Mon Nov 14 15:51:42 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 14 Nov 2022 15:51:42 GMT
Subject: RFR: 8249693:
 java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id
 [v2]
In-Reply-To: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
References: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
Message-ID: <Nk70VFVqiIvgoAjoFkva4CTLViT-CyqQGgu0yk16Xag=.b185b6f4-ab3f-45cb-8c9c-c7626e33a7d2@github.com>

> Added a check that source and destination volumes have enough space to run the test.
> 
> This test will no longer be ignored.

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

  added requires/fixed formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11028/files
  - new: https://git.openjdk.org/jdk/pull/11028/files/be28f3e7..e7049856

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

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

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

From duke at openjdk.org  Mon Nov 14 17:28:51 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 14 Nov 2022 17:28:51 GMT
Subject: RFR: 8249693:
 java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id
 [v2]
In-Reply-To: <9H2tmCmaxtVYbfqxQMr4Wc48ujyvLVko1zWcbrYmWUM=.360a15f4-8ca9-4e15-ac90-15ac74a309c1@github.com>
References: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
 <9H2tmCmaxtVYbfqxQMr4Wc48ujyvLVko1zWcbrYmWUM=.360a15f4-8ca9-4e15-ac90-15ac74a309c1@github.com>
Message-ID: <cnrStx2ZHm_f3lobf07Epyqs21ax5OMOWlXjOuvk5ww=.66891f2f-b9f1-46ab-9920-aa71e96144ea@github.com>

On Sun, 13 Nov 2022 16:51:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added requires/fixed formatting
>
> test/jdk/java/nio/channels/FileChannel/FileExtensionAndMap.java line 146:
> 
>> 144:             for (Path p : List.of(destinationPath, tmpDir)) {
>> 145:                 long usableDiskSpace = Files.getFileStore(p).getUsableSpace();
>> 146:                 if(usableDiskSpace < totalDiskSpaceNeeded) {
> 
> Suggestion:
> 
>                 if (usableDiskSpace < totalDiskSpaceNeeded) {

changed, thanks.

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

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

From bpb at openjdk.org  Mon Nov 14 20:01:16 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Nov 2022 20:01:16 GMT
Subject: RFR: 7132279: (ch) SeekableByteChannel operation may throw
 Non{Readable,Writable}ChannelException
Message-ID: <te1ivf7SScKcv9T41FcrQzeQ3b-eeMGw5j9sMRQOtSg=.c6b1c770-ae66-4ecf-bfe4-50e8f9a87bbe@github.com>

Fix the specifications of the `read` and `write` methods in `SeekableByteChannel` and `FileChannel` to indicate that a `NonReadableChannelException` or `NonWritableChannelException`, respectively.

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

Commit messages:
 - 7132279: (ch) SeekableByteChannel operation may throw Non{Readable,Writable}ChannelException

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

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

From bpb at openjdk.org  Mon Nov 14 20:01:17 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Nov 2022 20:01:17 GMT
Subject: RFR: 7132279: (ch) SeekableByteChannel operation may throw
 Non{Readable,Writable}ChannelException
In-Reply-To: <te1ivf7SScKcv9T41FcrQzeQ3b-eeMGw5j9sMRQOtSg=.c6b1c770-ae66-4ecf-bfe4-50e8f9a87bbe@github.com>
References: <te1ivf7SScKcv9T41FcrQzeQ3b-eeMGw5j9sMRQOtSg=.c6b1c770-ae66-4ecf-bfe4-50e8f9a87bbe@github.com>
Message-ID: <CyHDUX4yM7L2bhxUfeD_3nihTedWdrxpvkC8sHxP53s=.be1c33a6-13ef-46f6-a338-029f97a3c29b@github.com>

On Mon, 14 Nov 2022 19:19:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Fix the specifications of the `read` and `write` methods in `SeekableByteChannel` and `FileChannel` to indicate that a `NonReadableChannelException` or `NonWritableChannelException`, respectively.

There is no behavioral change.

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

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

From lancea at openjdk.org  Mon Nov 14 20:07:33 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Nov 2022 20:07:33 GMT
Subject: RFR: 7132279: (ch) SeekableByteChannel operation may throw
 Non{Readable,Writable}ChannelException
In-Reply-To: <te1ivf7SScKcv9T41FcrQzeQ3b-eeMGw5j9sMRQOtSg=.c6b1c770-ae66-4ecf-bfe4-50e8f9a87bbe@github.com>
References: <te1ivf7SScKcv9T41FcrQzeQ3b-eeMGw5j9sMRQOtSg=.c6b1c770-ae66-4ecf-bfe4-50e8f9a87bbe@github.com>
Message-ID: <4O9UNvax7fYhNXKqMn1NaJEUbUVTjTWPDp111ZsDtCw=.9a889762-1e0c-4c0f-92b2-5a4a8f7fe07c@github.com>

On Mon, 14 Nov 2022 19:19:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Fix the specifications of the `read` and `write` methods in `SeekableByteChannel` and `FileChannel` to indicate that a `NonReadableChannelException` or `NonWritableChannelException`, respectively.

Marked as reviewed by lancea (Reviewer).

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

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

From jpai at openjdk.org  Tue Nov 15 06:12:59 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 15 Nov 2022 06:12:59 GMT
Subject: RFR: 7132279: (ch) SeekableByteChannel operation may throw
 Non{Readable,Writable}ChannelException
In-Reply-To: <te1ivf7SScKcv9T41FcrQzeQ3b-eeMGw5j9sMRQOtSg=.c6b1c770-ae66-4ecf-bfe4-50e8f9a87bbe@github.com>
References: <te1ivf7SScKcv9T41FcrQzeQ3b-eeMGw5j9sMRQOtSg=.c6b1c770-ae66-4ecf-bfe4-50e8f9a87bbe@github.com>
Message-ID: <9wdsmBhusz5KAdWlkESSa9PXjxgKygmP-buV9trmiwo=.45e6821a-6a69-481a-99eb-0497b057f117@github.com>

On Mon, 14 Nov 2022 19:19:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Fix the specifications of the `read` and `write` methods in `SeekableByteChannel` and `FileChannel` to indicate that a `NonReadableChannelException` or `NonWritableChannelException`, respectively.

Marked as reviewed by jpai (Reviewer).

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

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

From mkartashev at openjdk.org  Tue Nov 15 10:00:29 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 15 Nov 2022 10:00:29 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v10]
In-Reply-To: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
Message-ID: <K0vkQwCONYUppMPTeeFg_v15LvT1_t8pvHVFQRtE2_g=.ee90fe13-2f26-4134-97c1-85f12fd7f79b@github.com>

> This is an implementation of `WatchService` based on File System Events API that is capable of generating events whenever a change occurs in an interesting directory or underneath it. Since the API naturally supports "recursive" watch, the `FILE_TREE` is supported by the watch service. 
> 
> Some things of note:
> * There's one "service" thread per `WatchService` instance that is inactive unless changes occur in the watched directory. The changes are grouped by introducing a time delay between when they occurred and when they are reported, which is controlled by the sensitivity modifier of the watch service.
> * Since FSEvents API reports directories only, the watch service keeps a snapshot (hierarchical if necessary) of the files in the directory being watched. The snapshot gets updated when an event in that directory or underneath it gets delivered. File changes are detected by comparing "last modified" time with a millisecond precision (`BasicFileAttributes.lastModifiedTime()`).
> * There is a slight complication with the move of an entire directory hierarchy: FSEvents API only reports about the containing directory of that move and not about any of the directories actually moved. There's a separate test for that (`Move.java`).
> * The code is careful not to do any I/O (such as reading the contents of a directory or attributes of a file) unless unavoidable. Any deviation from this line should be considered a bug (of, arguably, low priority).
> * The native part consists mostly of API wrappers with one exception of the callback function invoked by the system to report the events that occurred. The sole task of the function is to convert from C strings to Java strings and pass the array of affected directories to Java code. This can be rewritten if desired to make the code more future-proof.
> 
> This commit leaves `PollingWatchService` unused. I'm not sure if I should/can do anything about it. Any advice is welcomed.
> 
> ### Testing
> 
> * Tested by running `test/jdk/java/nio/file` and `test/jdk/jdk/nio` on MacOS 10.15.7 (x64) and `test/jdk/java/nio/` plus `test/jdk/jdk/nio` on MacOS 12.5.1 (aarch64).
> * Also verified that new tests pass on Linux and Windows.
> * This code (albeit in a slightly modified form) has been in use at JetBrains for around half a year and a few bugs have been found and fixed during that time period.

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

  Temporary auxiliary tracing to aid in debugging test failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10140/files
  - new: https://git.openjdk.org/jdk/pull/10140/files/805c94f3..8bed2635

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

  Stats: 33 lines in 3 files changed: 32 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10140.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10140/head:pull/10140

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

From mcimadamore at openjdk.org  Tue Nov 15 10:08:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 10:08:22 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v18]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <0aDgn8bkT3gjULRqLX7_1doqGRJhDlva7S3Q-uYBtZ4=.23b372a9-8775-4d0c-900f-c8a12d1769b1@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Tweak preview feature description for JEP 434

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/cd3fbe7c..9b97bad6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=16-17

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

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

From mkartashev at openjdk.org  Tue Nov 15 10:09:05 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 15 Nov 2022 10:09:05 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
Message-ID: <hmqV92znlcHodK2Mow3y66X7bxOb7x3Y4oF1n4Pub40=.4657de2e-da2c-47c2-b264-ed8fe1d3635d@github.com>

On Sun, 13 Nov 2022 15:29:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> In our CI system `test/jdk/java/nio/file/WatchService/Move.java` appears to time out consistently, although I have not seen it happen on my local machine.
>> 
>> Can you provide the `.jtr` file, please? I haven't seen the test hang, but by inserting different delays different systems can expose synchronization issues, of course.
>
>> In our CI system `test/jdk/java/nio/file/WatchService/Move.java` appears to time out consistently, although I have not seen it happen on my local machine.
> 
> I've been backed up with other things and finally getting to look at this more closely. For testing, I tried both release and debug builds across a range of macOS releases on both x64 and aarch64. Unfortunately there is a lot of timeouts and intermittent failures and across quite a range of macOS releases (from 10.15 to 12.2).
> 
> The most frequent failure seems to be the testOverflowEvent test in LotsOfEvents.  Here's an example failure:
> 
> ----------System.out:(1/47)----------
> Seed from RandomFactory = 1932318894124342221L
> ----------System.err:(12/655)----------
> java.lang.RuntimeException: Key not signalled (unexpected)
> 	at LotsOfEvents.drainAndCheckOverflowEvents(LotsOfEvents.java:105)
> 	at LotsOfEvents.testOverflowEvent(LotsOfEvents.java:78)
> 	at LotsOfEvents.main(LotsOfEvents.java:51)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:1591)

@AlanBateman still can't reproduce any of that on my hardware, so I added some tracing so that next time tests are run we can at least see what's happening.

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

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

From mcimadamore at openjdk.org  Tue Nov 15 10:12:12 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 10:12:12 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v19]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <43YEgUwCbX4IMeM2AjG_ZAytW-ibfIqCPW1fmBoYDpQ=.e2ef76bd-b10b-4785-976b-974501043f28@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

Maurizio Cimadamore 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 49 additional commits since the last revision:

 - Merge branch 'master' into PR_20
 - Tweak preview feature description for JEP 434
 - Tweak Arena::close javadoc
 - Merge pull request #15 from minborg/test
   
   Add @apiNote to package-info
 - Add @apiNote to package-info
 - Merge pull request #16 from minborg/fix-tests2
   
   Fix failing tests
 - Fix failing tests
 - Rename isOwnedBy -> isCloseableBy
   Fix minor typos
   Fix StrLenTest/RingAllocator
 - Fix typo
 - More javadoc fixes
 - ... and 39 more: https://git.openjdk.org/jdk/compare/0ecc71f0...20ee6e8d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/9b97bad6..20ee6e8d

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

  Stats: 15095 lines in 530 files changed: 6855 ins; 6001 del; 2239 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

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

From mcimadamore at openjdk.org  Tue Nov 15 11:14:35 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 11:14:35 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v20]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <uH-g-J7i6tgekoK2MJkbkul4wi9QTsh6aQIG46heMIQ=.3886b8e6-a605-4d6f-bb78-844c80a73a1e@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Rename MemorySession -> SegmentScope
  Improve javadoc of SegmentScope/Arena
  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/20ee6e8d..5ae5864a

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

  Stats: 1298 lines in 125 files changed: 174 ins; 177 del; 947 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

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

From mcimadamore at openjdk.org  Tue Nov 15 11:16:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 11:16:22 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v19]
In-Reply-To: <43YEgUwCbX4IMeM2AjG_ZAytW-ibfIqCPW1fmBoYDpQ=.e2ef76bd-b10b-4785-976b-974501043f28@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <43YEgUwCbX4IMeM2AjG_ZAytW-ibfIqCPW1fmBoYDpQ=.e2ef76bd-b10b-4785-976b-974501043f28@github.com>
Message-ID: <8jsBP6xJ2lT5UEIEHaGfI_Juqtj_pD1Plp7oynz81Zo=.695ba1b6-bfa9-442d-9cf2-425a7ed5a352@github.com>

On Tue, 15 Nov 2022 10:12:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore 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 49 additional commits since the last revision:
> 
>  - Merge branch 'master' into PR_20
>  - Tweak preview feature description for JEP 434
>  - Tweak Arena::close javadoc
>  - Merge pull request #15 from minborg/test
>    
>    Add @apiNote to package-info
>  - Add @apiNote to package-info
>  - Merge pull request #16 from minborg/fix-tests2
>    
>    Fix failing tests
>  - Fix failing tests
>  - Rename isOwnedBy -> isCloseableBy
>    Fix minor typos
>    Fix StrLenTest/RingAllocator
>  - Fix typo
>  - More javadoc fixes
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/3ebf94de...20ee6e8d

I've renamed `MemorySession` to `SegmentScope`, following some internal and external feedback. I've also greatly improved the javadoc of both `Arena` and `SegmentScope`. A javadoc of the API contained in this iteration can be found here:

http://cr.openjdk.java.net/~mcimadamore/jdk/8295044/v3/javadoc/java.base/module-summary.html

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

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

From mcimadamore at openjdk.org  Tue Nov 15 11:19:26 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 11:19:26 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v21]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <I7SjmaES3c_FaGDMQXN3JC-RmlSuA2iU7adIq3jhRzE=.21342938-1f80-40d0-b843-3dd522da34bb@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Fix whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/5ae5864a..3d9cebde

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

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

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

From mik3hall at gmail.com  Tue Nov 15 11:20:42 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 15 Nov 2022 05:20:42 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v8]
In-Reply-To: <52956209-5A07-49F5-B32B-F603D6867C06@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <h_gfCViVs9KuMeIhDCNzGD4N8wE57ArJM-T2EGyYzP4=.3c87b1de-2e58-44b5-85cb-3e66dd9dca22@github.com>
 <ay4oDKjwTh1VmbQlijzYRv7z3H0XSZB3TfiatnBZkDY=.42148f56-389b-4526-bf35-fc1789d57e73@github.com>
 <Nf4JhsYqnMvgXYoKLnBeeuRNdTlh_q8INM-rpyKxnQM=.71f14f0b-dfb9-4b9b-ad04-d69e5d2d5b4f@github.com>
 <8WHg8QPgBC2O2sYDXXHnL3Y2nS20dlzyUxRjr5r4Ctg=.2b07af8d-cc32-4f4f-bc6b-e043e6df66f7@github.com>
 <FQNZShhp0bmnGswXBPaZ8rYHSAgi1W3K5b6rVZWWlZM=.f1864e4f-5fd1-46c1-a5fc-67834fb19411@github.com>
 <ICUZ0-PGeM8QASztgXve5VGbs0ILVvClftlh9IRG_Zs=.5626c42e-4515-4def-b423-b29a57e4cca0@github.com>
 <fvqcSgHN-uY9Yn8QUGE0LeNM7XA2ZSMKA3EUZrcPSn0=.bb9502ad-022f-422a-9111-1f2595d7def9@github.com>
 <damJwQy4xc5ZF7EAwdXZjAadaT9kw7fOFK4-eMiqdZA=.97919808-1445-4d11-a7e0-831280c6f752@github.com>
 <52956209-5A07-49F5-B32B-F603D6867C06@gmail.com>
Message-ID: <E28DE3EE-A820-454B-80A3-646D1195F74F@gmail.com>



>> 
> 
> This still doesn?t appear to show local errors for me. I ran a modified LotsOfEvents 5 times which should amount to actually 25 test runs including concurrently. Without an error.
> 
>     

Since timeouts were previously mentioned, for my modified test of 5 LotsOfEvents For overflow polling uses slightly less elapsed millis than FSEvents averaging 32165.8 to 32227.4.
But for the queuing test it is noticeably worse, 39012.2 to 25067.4

> newov <- c(32256,32258,32216,32216,32191)
> newq <- c(25072,25074,25064,25064,25063)
> mean(newov)
[1] 32227.4
> mean(newq)
[1] 25067.4
> oldov <- c(32180,32180,32167,32167,32135)
> oldq <- c(39014,39014,39010,39010,39013)
> mean(oldov)
[1] 32165.8
> mean(oldq)
[1] 39012.2

(jconsole didn?t show the gc difference that the bitcoin monitor did, no significant differences were apparent, although polling still showed slightly higher CPU)

From mcimadamore at openjdk.org  Tue Nov 15 12:34:43 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 12:34:43 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Add `since` tag in Module/ModuleLayer preview methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/3d9cebde..b2dd8926

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

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

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

From pminborg at openjdk.org  Tue Nov 15 14:43:08 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Nov 2022 14:43:08 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
Message-ID: <UdYyCJV-_meAqSHaXCtWLJUKBekOlGf1aayXSOanXvE=.2f160547-8912-4194-9f2d-1010a3409985@github.com>

On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `since` tag in Module/ModuleLayer preview methods

src/java.base/share/classes/java/lang/foreign/Arena.java line 32:

> 30: 
> 31: /**
> 32:  * An arena controls the lifecycle of one or more memory segments, providing both flexible allocation and timely deallocation.

Strictly: "An arena controls the lifecycle of zero or more ...". A newly created Arena, for example, does not control the lifecycle of any segment.

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

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

From pminborg at openjdk.org  Tue Nov 15 14:48:01 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Nov 2022 14:48:01 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
Message-ID: <213057Saw0-m7uFTwDAgWYorxtjExq17nhZ0ULRUWGk=.1a10e475-baf5-4c71-a5af-c6288d3db6cc@github.com>

On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `since` tag in Module/ModuleLayer preview methods

src/java.base/share/classes/java/lang/foreign/Arena.java line 35:

> 33:  * <p>
> 34:  * An arena has a {@linkplain #scope() scope}, called the arena scope. When the arena is {@linkplain #close() closed},
> 35:  * the arena scope becomes not {@linkplain SegmentScope#isAlive() alive}. As a result, all the

Suggest "the arena scope is no longer {@linkplain SegmentScope#isAlive() alive}" instead.

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

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

From pminborg at openjdk.org  Tue Nov 15 14:52:05 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Nov 2022 14:52:05 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
Message-ID: <A58FkB5AN2EXrL-ULzZNkWLrVVCR-bddo8Cj7vwmoPo=.cb1ca360-69e3-46fe-9213-747011b24fdb@github.com>

On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `since` tag in Module/ModuleLayer preview methods

src/java.base/share/classes/java/lang/foreign/Arena.java line 63:

> 61:  * <em>after</em> the arena has been closed. The cost of providing this guarantee varies based on the
> 62:  * number of threads that have access to the memory segments allocated by the arena. For instance, if an arena
> 63:  * is always created and closed by one thread, and the memory segments associated with the arena's scope are always

Strictly, if a shared segment is created and is only accessed by a single thread, then we need to track thread usage in order to trivially ensure safety. I think we could reword so that if access is only *allowed* by a single thread, it is trivial.

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

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

From pminborg at openjdk.org  Tue Nov 15 14:55:14 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Nov 2022 14:55:14 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <A58FkB5AN2EXrL-ULzZNkWLrVVCR-bddo8Cj7vwmoPo=.cb1ca360-69e3-46fe-9213-747011b24fdb@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
 <A58FkB5AN2EXrL-ULzZNkWLrVVCR-bddo8Cj7vwmoPo=.cb1ca360-69e3-46fe-9213-747011b24fdb@github.com>
Message-ID: <pgAYr6yivaGfYQqw5oZsMEphXH7AL6mYGwsIaq6VRIE=.b7d60942-0f07-4b4f-887d-6c1651488e8d@github.com>

On Tue, 15 Nov 2022 14:49:30 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add `since` tag in Module/ModuleLayer preview methods
>
> src/java.base/share/classes/java/lang/foreign/Arena.java line 63:
> 
>> 61:  * <em>after</em> the arena has been closed. The cost of providing this guarantee varies based on the
>> 62:  * number of threads that have access to the memory segments allocated by the arena. For instance, if an arena
>> 63:  * is always created and closed by one thread, and the memory segments associated with the arena's scope are always
> 
> ~~Strictly, if a shared segment is created and is only accessed by a single thread, then we need to track thread usage in order to trivially ensure safety. I think we could reword so that if access is only *allowed* by a single thread, it is trivial.~~

ok. So reading on the initial text makes sense. So, my comment above should be disregarded.

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

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

From pminborg at openjdk.org  Tue Nov 15 15:00:08 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Nov 2022 15:00:08 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
Message-ID: <GIKXOkQmr1nrn7_PkKpuK53NXxgvLUQZtUXAp8Ba0Y4=.df3ebc05-0ce9-429b-9bc9-420ae3ce93d9@github.com>

On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `since` tag in Module/ModuleLayer preview methods

src/java.base/share/classes/java/lang/foreign/Arena.java line 79:

> 77:  * <p>
> 78:  * Shared arenas, on the other hand, have no owner thread. The segments created by a shared arena
> 79:  * can be {@linkplain SegmentScope#isAccessibleBy(Thread) accessed} by multiple threads. This might be useful when

Suggest "can be {@linkplain SegmentScope#isAccessibleBy(Thread) accessed} by ~~multiple~~ *any* thread"

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

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

From pminborg at openjdk.org  Tue Nov 15 15:11:15 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Nov 2022 15:11:15 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
Message-ID: <7T_4KxIMV_s9h3OjbniZId7ridKlYeJ1sXu3tgBor2c=.9e0d8f95-554b-4dc3-8b1b-27e78f85578d@github.com>

On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `since` tag in Module/ModuleLayer preview methods

src/java.base/share/classes/java/lang/foreign/Arena.java line 89:

> 87: 
> 88:     /**
> 89:      * Returns a native memory segment with the given size (in bytes) and alignment constraint (in bytes).

It is noted that the current documentation does not require a **new** native memory segment to be returned. Would it not be better with:

Creates a new native memory segment ...

The new shared segment might share actual backing memory though.

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

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

From pminborg at openjdk.org  Tue Nov 15 15:15:45 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Nov 2022 15:15:45 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
Message-ID: <NH1uMbxG-JN-dA5cVca_NycjgMIfSVcTVnABKROOGuQ=.bb383e54-90ab-4207-915a-11e11db80b27@github.com>

On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `since` tag in Module/ModuleLayer preview methods

src/java.base/share/classes/java/lang/foreign/Arena.java line 119:

> 117: 
> 118:     /**
> 119:      * {@return the arena scope}

Add a period ('.') after the closing curly bracket.

src/java.base/share/classes/java/lang/foreign/Arena.java line 124:

> 122: 
> 123:     /**
> 124:      * Closes this arena. If this method completes normally, the arena scope becomes not {@linkplain SegmentScope#isAlive() alive},

See comment above "not alive" -> "is no longer alive"

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

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

From pminborg at openjdk.org  Tue Nov 15 15:07:04 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Nov 2022 15:07:04 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
Message-ID: <E4F8uEhS_Dlj_o8mY5HFtYp_mMRCIutC47dNOPxHWeo=.2db3c5cb-12d7-4a39-9a36-e619bfe3d95e@github.com>

On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `since` tag in Module/ModuleLayer preview methods

src/java.base/share/classes/java/lang/foreign/Arena.java line 100:

> 98:      * MemorySegment.allocateNative(bytesSize, byteAlignment, scope());
> 99:      *}
> 100:      * More generally implementations of this method must return a native method featuring the requested size,

... must return a native ~~method~~*segment* featuring ...

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

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

From pminborg at openjdk.org  Tue Nov 15 15:34:17 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Nov 2022 15:34:17 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
Message-ID: <rolvXeYI5PDmoX-Q5l7obDmasgTF9Dzk-dOMmMO80ug=.3423895e-bf7a-427e-becb-b76479f6c72f@github.com>

On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `since` tag in Module/ModuleLayer preview methods

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 163:

> 161:  * segment is derived from the address of the original segment, by adding an offset (expressed in bytes). The size of
> 162:  * the sliced segment is either derived implicitly (by subtracting the specified offset from the size of the original segment),
> 163:  * or provided explicitly. In other words, a sliced segment has <em>stricter</em> spatial bounds than those of the original segment:

Strictly, a sliced segment can have the *same* spatial bounds as the original segment.

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

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

From pminborg at openjdk.org  Tue Nov 15 15:28:52 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Nov 2022 15:28:52 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
Message-ID: <D5wT2ztN28Ffda06oR6nz-pB_1Tz7Wli1JP-PDuRlp0=.aa077176-1e7a-44f7-9aa1-7c20eb40a2da@github.com>

On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `since` tag in Module/ModuleLayer preview methods

src/java.base/share/classes/java/lang/foreign/Arena.java line 136:

> 134: 
> 135:     /**
> 136:      * {@return {@code true} if the provided thread can close this arena}

I think this is equivalent and simpler:

{@return if the provided thread can close this arena}.

But I know there are many examples of {@code true} in the JDK.

src/java.base/share/classes/java/lang/foreign/GroupLayout.java line 46:

> 44: 
> 45:     /**
> 46:      * Returns the member layouts associated with this group.

We may use {@return the member layouts associated with this group}.

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

> 262: 
> 263:     /**
> 264:      * Returns a symbol lookup for symbols in a set of commonly used libraries.

Use {@return ...}

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

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

From mcimadamore at openjdk.org  Tue Nov 15 15:38:52 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 15:38:52 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <rolvXeYI5PDmoX-Q5l7obDmasgTF9Dzk-dOMmMO80ug=.3423895e-bf7a-427e-becb-b76479f6c72f@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
 <rolvXeYI5PDmoX-Q5l7obDmasgTF9Dzk-dOMmMO80ug=.3423895e-bf7a-427e-becb-b76479f6c72f@github.com>
Message-ID: <v8I8-DqGKUAuLfw90GJxVUw8do6sZO_xUb5sALQ_bII=.6992ccd9-0da3-46d8-b819-bc7bfdc22da6@github.com>

On Tue, 15 Nov 2022 15:31:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add `since` tag in Module/ModuleLayer preview methods
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 163:
> 
>> 161:  * segment is derived from the address of the original segment, by adding an offset (expressed in bytes). The size of
>> 162:  * the sliced segment is either derived implicitly (by subtracting the specified offset from the size of the original segment),
>> 163:  * or provided explicitly. In other words, a sliced segment has <em>stricter</em> spatial bounds than those of the original segment:
> 
> Strictly, a sliced segment can have the *same* spatial bounds as the original segment.

True - but I think the current text is a good compromise e.g. it is narrative text. You can always dive into `MemorySegment::asSlice` and find out more.

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

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

From mcimadamore at openjdk.org  Tue Nov 15 15:38:49 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 15:38:49 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <wE3yFS78OA3hPMr2hdx-Cn1prEWIMbwkWKgPJyXhMcM=.941de4e5-e85a-4739-a1f8-ba58a552481d@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
 <7T_4KxIMV_s9h3OjbniZId7ridKlYeJ1sXu3tgBor2c=.9e0d8f95-554b-4dc3-8b1b-27e78f85578d@github.com>
 <wE3yFS78OA3hPMr2hdx-Cn1prEWIMbwkWKgPJyXhMcM=.941de4e5-e85a-4739-a1f8-ba58a552481d@github.com>
Message-ID: <LkU1oaYtTflIao6PXDvdw52m4DQczQJuEIcw61PdtdA=.6134e6c4-4883-468a-9414-7b305428e03a@github.com>

On Tue, 15 Nov 2022 15:22:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Arena.java line 89:
>> 
>>> 87: 
>>> 88:     /**
>>> 89:      * Returns a native memory segment with the given size (in bytes) and alignment constraint (in bytes).
>> 
>> It is noted that the current documentation does not require a **new** native memory segment to be returned. Would it not be better with:
>> 
>> Creates a new native memory segment ...
>> 
>> The new shared segment might share actual backing memory though.
>
> My feeling is that being overly precise over identity might backfire. It is not important whether the segment is a new instance or not. But there is, perhaps, another invariant that is more semantically relevant: e.g. the returned segments (whether new or not, we don't care) should be backed by "disjoint" regions of memory. That is, if the method returns a segment with address `0` and size `100`, calling the method again cannot return a segment whose address is `50` and size is `100`. In principle, the segment allocator interface allows for this (see `SegmentAllocator::prefixAllocator`) - but for an arena, a behavior such as this would be indesirable, IMHO.

I will add:


Furthermore, for any two segments S1, S2 returned by this method, the following invariant must hold:

 S1.overlappingSlice(S2).isEmpty() == true
 ```

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

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

From mcimadamore at openjdk.org  Tue Nov 15 15:28:50 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 15:28:50 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v22]
In-Reply-To: <7T_4KxIMV_s9h3OjbniZId7ridKlYeJ1sXu3tgBor2c=.9e0d8f95-554b-4dc3-8b1b-27e78f85578d@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <IChQ_tWAjGyOjB9_sxwMmW79pGr_v-2s8F9-i_suhXw=.465a1051-fdb9-4715-a7e3-0608a78a3ba1@github.com>
 <7T_4KxIMV_s9h3OjbniZId7ridKlYeJ1sXu3tgBor2c=.9e0d8f95-554b-4dc3-8b1b-27e78f85578d@github.com>
Message-ID: <wE3yFS78OA3hPMr2hdx-Cn1prEWIMbwkWKgPJyXhMcM=.941de4e5-e85a-4739-a1f8-ba58a552481d@github.com>

On Tue, 15 Nov 2022 15:09:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add `since` tag in Module/ModuleLayer preview methods
>
> src/java.base/share/classes/java/lang/foreign/Arena.java line 89:
> 
>> 87: 
>> 88:     /**
>> 89:      * Returns a native memory segment with the given size (in bytes) and alignment constraint (in bytes).
> 
> It is noted that the current documentation does not require a **new** native memory segment to be returned. Would it not be better with:
> 
> Creates a new native memory segment ...
> 
> The new shared segment might share actual backing memory though.

My feeling is that being overly precise over identity might backfire. It is not important whether the segment is a new instance or not. But there is, perhaps, another invariant that is more semantically relevant: e.g. the returned segments (whether new or not, we don't care) should be backed by "disjoint" regions of memory. That is, if the method returns a segment with address `0` and size `100`, calling the method again cannot return a segment whose address is `50` and size is `100`. In principle, the segment allocator interface allows for this (see `SegmentAllocator::prefixAllocator`) - but for an arena, a behavior such as this would be indesirable, IMHO.

> src/java.base/share/classes/java/lang/foreign/Arena.java line 119:
> 
>> 117: 
>> 118:     /**
>> 119:      * {@return the arena scope}
> 
> Add a period ('.') after the closing curly bracket. This is a general comment.

I don't think we did this consistently in other places, I'd prefer to leave as is.

> src/java.base/share/classes/java/lang/foreign/Arena.java line 136:
> 
>> 134: 
>> 135:     /**
>> 136:      * {@return {@code true} if the provided thread can close this arena}
> 
> I think this is equivalent and simpler:
> 
> {@return if the provided thread can close this arena}.
> 
> But I know there are many examples of {@code true} in the JDK.

I'll leave as is - we can deal with this cosmetic javadoc issues at a later point.

> src/java.base/share/classes/java/lang/foreign/GroupLayout.java line 46:
> 
>> 44: 
>> 45:     /**
>> 46:      * Returns the member layouts associated with this group.
> 
> We may use {@return the member layouts associated with this group}.

Same - I'll leave these tweaks for later.

> src/java.base/share/classes/java/lang/foreign/Linker.java line 264:
> 
>> 262: 
>> 263:     /**
>> 264:      * Returns a symbol lookup for symbols in a set of commonly used libraries.
> 
> Use {@return ...}

Same - I'll leave these tweaks for later.

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

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

From mcimadamore at openjdk.org  Tue Nov 15 15:58:46 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 15:58:46 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v24]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <2K-hydg-uLovxuhq4-WgeYlZPtj-INuCGlEKieRg77E=.de717cd6-8104-4402-b935-7ccb90199e4f@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Fix tests broken by MemorySession rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/19e0f6d5..54fb4856

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=22-23

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

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

From mcimadamore at openjdk.org  Tue Nov 15 15:48:28 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 15:48:28 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v23]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <ICzcAF5BFn7G7mmNhTYJZNn2RWaqoUIjzP_uhEC_CtU=.28040345-a748-464a-ba9d-1e4e31ce368f@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/b2dd8926..19e0f6d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=21-22

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

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

From mcimadamore at openjdk.org  Tue Nov 15 17:54:16 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 17:54:16 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v25]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <-RoscJ-7QuJ7y50zTBcxRISETzsAnuWdhDjOKhkcLoU=.99cc6f49-c850-4d93-a40b-4cd953a99cb2@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Fix MapToMemorySegmentTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/54fb4856..b331a4fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=23-24

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

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

From mcimadamore at openjdk.org  Tue Nov 15 18:03:39 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 18:03:39 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v26]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <-rih5SODHs0oMsQlaTc_lny0Cz6YvYLa4Arjr3Sf0fA=.755847f0-6a14-4784-85ba-97be21e6656b@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Fix @since tag in SegmentScope

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/b331a4fd..5f60d052

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=24-25

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

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

From mcimadamore at openjdk.org  Tue Nov 15 18:47:39 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 18:47:39 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v27]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Fix typo in SegmentScope javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/5f60d052..876587c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=25-26

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

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

From alanb at openjdk.org  Wed Nov 16 08:14:02 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Nov 2022 08:14:02 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
Message-ID: <vK98Lx7Y5Z9zH6ag4bSmnjZoKBBsJ_NwfEFogZGW8Uo=.202b0824-938f-4e2b-9694-53c6e9b433dc@github.com>

On Sun, 13 Nov 2022 15:29:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> In our CI system `test/jdk/java/nio/file/WatchService/Move.java` appears to time out consistently, although I have not seen it happen on my local machine.
>> 
>> Can you provide the `.jtr` file, please? I haven't seen the test hang, but by inserting different delays different systems can expose synchronization issues, of course.
>
>> In our CI system `test/jdk/java/nio/file/WatchService/Move.java` appears to time out consistently, although I have not seen it happen on my local machine.
> 
> I've been backed up with other things and finally getting to look at this more closely. For testing, I tried both release and debug builds across a range of macOS releases on both x64 and aarch64. Unfortunately there is a lot of timeouts and intermittent failures and across quite a range of macOS releases (from 10.15 to 12.2).
> 
> The most frequent failure seems to be the testOverflowEvent test in LotsOfEvents.  Here's an example failure:
> 
> ----------System.out:(1/47)----------
> Seed from RandomFactory = 1932318894124342221L
> ----------System.err:(12/655)----------
> java.lang.RuntimeException: Key not signalled (unexpected)
> 	at LotsOfEvents.drainAndCheckOverflowEvents(LotsOfEvents.java:105)
> 	at LotsOfEvents.testOverflowEvent(LotsOfEvents.java:78)
> 	at LotsOfEvents.main(LotsOfEvents.java:51)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:1591)

> @AlanBateman still can't reproduce any of that on my hardware, so I added some tracing so that next time tests are run we can at least see what's happening.

LotsOfEvents.java on macOS 12.2

----------stdout:(7/337)----------
WatchService: get run loop -> 600003a5c500
WatchService: running run loop 600003a5c500
WatchService: created event stream 101105150
WatchService: scheduled event stream 101105150 on run loop 600003a5c500
WatchService: running run loop 600003a5c500
WatchService: stopped event stream 101105150
WatchService: stopped run loop 600003a5c500
----------System.out:(10/421)----------
Seed from RandomFactory = 5027502271796047304L
WatchService: Run loop 600003a5c500 - waiting...
WatchService: Run loop 600003a5c500 - starting...
Test: dir.register - start
WatchService: Run loop 600003a5c500 - waiting for event source...
Test: dir.register - done
WatchService: Run loop 600003a5c500 - starting...
Test: created files
Test: About to poll
WatchService: Run loop 600003a5c500 - waiting for event source...
----------System.err:(12/655)----------
java.lang.RuntimeException: Key not signalled (unexpected)
	at LotsOfEvents.drainAndCheckOverflowEvents(LotsOfEvents.java:112)
	at LotsOfEvents.testOverflowEvent(LotsOfEvents.java:84)
	at LotsOfEvents.main(LotsOfEvents.java:51)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:1591)

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

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Key not signalled (unexpected)


DeleteInterference.java also  on macOS 12.2, this one is a timeout:

open 292 end
open 293 begin
WatchService: Run loop 6000004a9000 - waiting...
WatchService: Run loop 6000004a9000 - starting...
WatchService: Run loop 6000004a9000 - waiting for event source...
open 293 end
open 294 begin
WatchService: Run loop 6000004ade00 - waiting...
WatchService: Run loop 6000004ade00 - starting...
WatchService: Run loop 6000004ade00 - waiting for event source...
WatchService: Run loop 6000004ade00 - starting...
WatchService: Run loop 60000
result: Error. Agent error: java.lang.Exception: Agent 8 timed out with a timeout of 480 seconds; check console log for any additional details

test result: Error. Agent error: java.lang.Exception: Agent 8 timed out with a timeout of 480 seconds; check console log for any additional details


The .jtr are huge due to all the tracing.

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

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

From alanb at openjdk.org  Wed Nov 16 16:04:17 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Nov 2022 16:04:17 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v27]
In-Reply-To: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
Message-ID: <Rcdl--DkeXEh4meWxeCpSm3hEIDQs6HyFUuAn7Kt4aY=.60d633a0-9f8d-4f45-bf6f-d52cdf279c66@github.com>

On Tue, 15 Nov 2022 18:47:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in SegmentScope javadoc

src/java.base/share/classes/java/lang/foreign/Arena.java line 132:

> 130:      * and all the memory segments associated with it can no longer be accessed. Furthermore, any off-heap region of memory backing the
> 131:      * segments associated with that scope are also released.
> 132:      * @throws IllegalStateException if the arena has already been {@linkplain #close() closed}.

It's not wrong to specify that close throw if already closed but it goes against the advice in AutoCloseable to try to have close methods be idempotent. There may be a good reason for this but I can't help wondering if there are error cases when wrapping that might lead to close being called more than once.

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

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

From alanb at openjdk.org  Wed Nov 16 16:16:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Nov 2022 16:16:22 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v27]
In-Reply-To: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
Message-ID: <Yr6tHpETjKb_0mE36rbbm9d9OVOmfl17SlaeglTrVTs=.2ed7bf1d-9869-4e03-81ad-6fdf7a7a94f7@github.com>

On Tue, 15 Nov 2022 18:47:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in SegmentScope javadoc

src/java.base/share/classes/java/lang/foreign/SegmentScope.java line 8:

> 6: 
> 7: /**
> 8:  * A segment scope controls access to a memory segment.

A passing comment here is that "to a memory segment" hints of one-to-one relationship when it's actually one-to-many. Arena is specified to control the lifecycle "of memory segments".

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

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

From mcimadamore at openjdk.org  Wed Nov 16 16:16:21 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Nov 2022 16:16:21 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v27]
In-Reply-To: <Rcdl--DkeXEh4meWxeCpSm3hEIDQs6HyFUuAn7Kt4aY=.60d633a0-9f8d-4f45-bf6f-d52cdf279c66@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
 <Rcdl--DkeXEh4meWxeCpSm3hEIDQs6HyFUuAn7Kt4aY=.60d633a0-9f8d-4f45-bf6f-d52cdf279c66@github.com>
Message-ID: <GxQqRxeRLyn3r7KOMt7peCz_dz2ih4Z7V2I7a0bm-tg=.6aafdbc9-cdf3-416d-aa5c-94c23640976f@github.com>

On Wed, 16 Nov 2022 16:01:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in SegmentScope javadoc
>
> src/java.base/share/classes/java/lang/foreign/Arena.java line 132:
> 
>> 130:      * and all the memory segments associated with it can no longer be accessed. Furthermore, any off-heap region of memory backing the
>> 131:      * segments associated with that scope are also released.
>> 132:      * @throws IllegalStateException if the arena has already been {@linkplain #close() closed}.
> 
> It's not wrong to specify that close throw if already closed but it goes against the advice in AutoCloseable to try to have close methods be idempotent. There may be a good reason for this but I can't help wondering if there are error cases when wrapping that might lead to close being called more than once.

In our experience with using the API, having exceptions when something is funny about close is very valuable info (as also stated in the javadoc). Almost always there's a subtle temporal bug going on which the ISE catches. I'm not sure if here you refer to the fact that the javadoc is being overly broad in saying "already been closed" instead of "already been closed _successfully_" ? What kind of problems are you thinking of?

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

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

From alanb at openjdk.org  Wed Nov 16 16:40:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Nov 2022 16:40:31 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v27]
In-Reply-To: <GxQqRxeRLyn3r7KOMt7peCz_dz2ih4Z7V2I7a0bm-tg=.6aafdbc9-cdf3-416d-aa5c-94c23640976f@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
 <Rcdl--DkeXEh4meWxeCpSm3hEIDQs6HyFUuAn7Kt4aY=.60d633a0-9f8d-4f45-bf6f-d52cdf279c66@github.com>
 <GxQqRxeRLyn3r7KOMt7peCz_dz2ih4Z7V2I7a0bm-tg=.6aafdbc9-cdf3-416d-aa5c-94c23640976f@github.com>
Message-ID: <YK0th_GmZZssrYNntdATL8n211gcqimnSNAFVv0_mFM=.870d9ed6-30bc-4eb9-874e-93e4c247c20b@github.com>

On Wed, 16 Nov 2022 16:13:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Arena.java line 132:
>> 
>>> 130:      * and all the memory segments associated with it can no longer be accessed. Furthermore, any off-heap region of memory backing the
>>> 131:      * segments associated with that scope are also released.
>>> 132:      * @throws IllegalStateException if the arena has already been {@linkplain #close() closed}.
>> 
>> It's not wrong to specify that close throw if already closed but it goes against the advice in AutoCloseable to try to have close methods be idempotent. There may be a good reason for this but I can't help wondering if there are error cases when wrapping that might lead to close being called more than once.
>
> In our experience with using the API, having exceptions when something is funny about close is very valuable info (as also stated in the javadoc). Almost always there's a subtle temporal bug going on which the ISE catches. I'm not sure if here you refer to the fact that the javadoc is being overly broad in saying "already been closed" instead of "already been closed _successfully_" ? What kind of problems are you thinking of?

Most of the AutoCloseable in the platform are Closeables where close is specified to have no effect when already closed. With a confined Arena it would be benign for the owner to invoke close again. If it's been useful at finding bugs then okay. The scenario that made me wonder about this is something like the follow where MyWrapper::close invokes Arena::close.

        try (var arena = Arena.openConfined();
             var wrapper = new MyWrapper(arena)) {
            :
        }

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

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

From mcimadamore at openjdk.org  Wed Nov 16 16:44:31 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Nov 2022 16:44:31 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v27]
In-Reply-To: <YK0th_GmZZssrYNntdATL8n211gcqimnSNAFVv0_mFM=.870d9ed6-30bc-4eb9-874e-93e4c247c20b@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
 <Rcdl--DkeXEh4meWxeCpSm3hEIDQs6HyFUuAn7Kt4aY=.60d633a0-9f8d-4f45-bf6f-d52cdf279c66@github.com>
 <GxQqRxeRLyn3r7KOMt7peCz_dz2ih4Z7V2I7a0bm-tg=.6aafdbc9-cdf3-416d-aa5c-94c23640976f@github.com>
 <YK0th_GmZZssrYNntdATL8n211gcqimnSNAFVv0_mFM=.870d9ed6-30bc-4eb9-874e-93e4c247c20b@github.com>
Message-ID: <IJd6eOdLK-bJOb-SfLTs7rDagHn4FlsBPOJPNKm7DAM=.c3688eed-8821-4d3a-89b1-1e767eb4810e@github.com>

On Wed, 16 Nov 2022 16:38:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In our experience with using the API, having exceptions when something is funny about close is very valuable info (as also stated in the javadoc). Almost always there's a subtle temporal bug going on which the ISE catches. I'm not sure if here you refer to the fact that the javadoc is being overly broad in saying "already been closed" instead of "already been closed _successfully_" ? What kind of problems are you thinking of?
>
> Most of the AutoCloseable in the platform are Closeables where close is specified to have no effect when already closed. With a confined Arena it would be benign for the owner to invoke close again. If it's been useful at finding bugs then okay. The scenario that made me wonder about this is something like the follow where MyWrapper::close invokes Arena::close.
> 
>         try (var arena = Arena.openConfined();
>              var wrapper = new MyWrapper(arena)) {
>             :
>         }

Actually, I see that the `@apiNote` we used to have has disappeared in the API reshuffling. I will add it back.

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

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

From mcimadamore at openjdk.org  Wed Nov 16 16:54:41 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Nov 2022 16:54:41 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v27]
In-Reply-To: <IJd6eOdLK-bJOb-SfLTs7rDagHn4FlsBPOJPNKm7DAM=.c3688eed-8821-4d3a-89b1-1e767eb4810e@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
 <Rcdl--DkeXEh4meWxeCpSm3hEIDQs6HyFUuAn7Kt4aY=.60d633a0-9f8d-4f45-bf6f-d52cdf279c66@github.com>
 <GxQqRxeRLyn3r7KOMt7peCz_dz2ih4Z7V2I7a0bm-tg=.6aafdbc9-cdf3-416d-aa5c-94c23640976f@github.com>
 <YK0th_GmZZssrYNntdATL8n211gcqimnSNAFVv0_mFM=.870d9ed6-30bc-4eb9-874e-93e4c247c20b@github.com>
 <IJd6eOdLK-bJOb-SfLTs7rDagHn4FlsBPOJPNKm7DAM=.c3688eed-8821-4d3a-89b1-1e767eb4810e@github.com>
Message-ID: <XldFLHsbVJyfLolNAa3nJjl1VyRWDqzec8sXXqs0Oqc=.58322b61-7fa0-49a8-91e5-3bddbfdef244@github.com>

On Wed, 16 Nov 2022 16:41:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Most of the AutoCloseable in the platform are Closeables where close is specified to have no effect when already closed. With a confined Arena it would be benign for the owner to invoke close again. If it's been useful at finding bugs then okay. The scenario that made me wonder about this is something like the follow where MyWrapper::close invokes Arena::close.
>> 
>>         try (var arena = Arena.openConfined();
>>              var wrapper = new MyWrapper(arena)) {
>>             :
>>         }
>
> Actually, I see that the `@apiNote` we used to have has disappeared in the API reshuffling. I will add it back.

> Most of the AutoCloseable in the platform are Closeables where close is specified to have no effect when already closed. With a confined Arena it would be benign for the owner to invoke close again. If it's been useful at finding bugs then okay. The scenario that made me wonder about this is something like the follow where MyWrapper::close invokes Arena::close.
> 
> ```
>         try (var arena = Arena.openConfined();
>              var wrapper = new MyWrapper(arena)) {
>             :
>         }
> ```

Sure - this would be problematic - however it seems an edge case (could the TWR just use MyWrapper?)

I'd prefer to leave it as is for now, and revisit - so far we had no indications of this being a real problem, whereas we had cases where the thrown exception has been useful to spot issues. If consistency with the rest of the JDK is considered more important we can fix it later.

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

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

From psandoz at openjdk.org  Wed Nov 16 16:54:47 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 16 Nov 2022 16:54:47 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v27]
In-Reply-To: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
Message-ID: <pwQc-QIMW2rHOtyW9Dmlx8ur4xvAHQuyMI_LzFMmLmo=.3c518cbf-7d68-4b73-9f22-d59478555ace@github.com>

On Tue, 15 Nov 2022 18:47:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in SegmentScope javadoc

src/java.base/share/classes/java/lang/foreign/Arena.java line 132:

> 130:      * and all the memory segments associated with it can no longer be accessed. Furthermore, any off-heap region of memory backing the
> 131:      * segments associated with that scope are also released.
> 132:      * @throws IllegalStateException if the arena has already been {@linkplain #close() closed}.

JavaDoc was pointing to itself.
Suggestion:

     * @throws IllegalStateException if the arena has already been closed.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 109:

> 107:  * Finally, access operations on a memory segment are subject to the thread-confinement checks enforced by the associated
> 108:  * scope; that is, if the segment is the {@linkplain SegmentScope#global() global scope} or an {@linkplain SegmentScope#auto() automatic scope},
> 109:  * it can be accessed by multiple threads. If the segment is associatd with an arena scope, then it can only be

Typo:
Suggestion:

 * it can be accessed by multiple threads. If the segment is associated with an arena scope, then it can only be

src/java.base/share/classes/java/lang/foreign/SegmentScope.java line 10:

> 8:  * A segment scope controls access to a memory segment.
> 9:  * <p>
> 10:  * A memory segment can only be accessed while its scope is {@linkplain #isAlive() alive}. Moreoever,

Typo:
Suggestion:

 * A memory segment can only be accessed while its scope is {@linkplain #isAlive() alive}. Moreover,

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

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

From bpb at openjdk.org  Wed Nov 16 17:35:50 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Nov 2022 17:35:50 GMT
Subject: Integrated: 7132279: (ch) SeekableByteChannel operation may throw
 Non{Readable,Writable}ChannelException
In-Reply-To: <te1ivf7SScKcv9T41FcrQzeQ3b-eeMGw5j9sMRQOtSg=.c6b1c770-ae66-4ecf-bfe4-50e8f9a87bbe@github.com>
References: <te1ivf7SScKcv9T41FcrQzeQ3b-eeMGw5j9sMRQOtSg=.c6b1c770-ae66-4ecf-bfe4-50e8f9a87bbe@github.com>
Message-ID: <Ewzhlcq_CVhvkTJRPsfI6tA4cYR-_WKHsCl1MxDCgbA=.397c251a-94bc-4ef4-9c2d-6ffc034e3271@github.com>

On Mon, 14 Nov 2022 19:19:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Fix the specifications of the `read` and `write` methods in `SeekableByteChannel` and `FileChannel` to indicate that a `NonReadableChannelException` or `NonWritableChannelException`, respectively.

This pull request has now been integrated.

Changeset: b97fc934
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b97fc934373d6fd515c70b2b7fde32fe63437597
Stats:     17 lines in 2 files changed: 8 ins; 9 del; 0 mod

7132279: (ch) SeekableByteChannel operation may throw Non{Readable,Writable}ChannelException

Reviewed-by: lancea, jpai

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

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

From mik3hall at gmail.com  Thu Nov 17 02:44:53 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 16 Nov 2022 20:44:53 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <hmqV92znlcHodK2Mow3y66X7bxOb7x3Y4oF1n4Pub40=.4657de2e-da2c-47c2-b264-ed8fe1d3635d@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <hmqV92znlcHodK2Mow3y66X7bxOb7x3Y4oF1n4Pub40=.4657de2e-da2c-47c2-b264-ed8fe1d3635d@github.com>
Message-ID: <C6F733EF-AAB0-4F29-85C5-C1E2DD0E0CF6@gmail.com>


> 
> @AlanBateman still can't reproduce any of that on my hardware, 
> 

Same using ?make test? besides my own modified. 

Passed: java/nio/file/WatchService/LotsOfEvents.java

> I've been backed up with other things and finally getting to look at this more closely. For testing, I tried both release and debug builds across a range of macOS releases on both x64 and aarch64. Unfortunately there is a lot of timeouts and intermittent failures and across quite a range of macOS releases (from 10.15 to 12.2).

Doesn?t this sort of sound like a threading/deadlock type issue? Intermittent - timeouts. Maybe your runloop concerns were well founded.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221116/95bac7a1/attachment-0001.htm>

From mik3hall at gmail.com  Thu Nov 17 02:49:55 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 16 Nov 2022 20:49:55 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <C6F733EF-AAB0-4F29-85C5-C1E2DD0E0CF6@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <hmqV92znlcHodK2Mow3y66X7bxOb7x3Y4oF1n4Pub40=.4657de2e-da2c-47c2-b264-ed8fe1d3635d@github.com>
 <C6F733EF-AAB0-4F29-85C5-C1E2DD0E0CF6@gmail.com>
Message-ID: <4D6F12D9-8D85-4A7E-A95E-AAC22FA2C5F9@gmail.com>



> On Nov 16, 2022, at 8:44 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
>> 
>> @AlanBateman still can't reproduce any of that on my hardware, 
>> 
> 
> Same using ?make test? besides my own modified. 
> 
> Passed: java/nio/file/WatchService/LotsOfEvents.java
> 
>> I've been backed up with other things and finally getting to look at this more closely. For testing, I tried both release and debug builds across a range of macOS releases on both x64 and aarch64. Unfortunately there is a lot of timeouts and intermittent failures and across quite a range of macOS releases (from 10.15 to 12.2).
> 
> Doesn?t this sort of sound like a threading/deadlock type issue? Intermittent - timeouts. Maybe your runloop concerns were well founded.

Or does this possibly go back to the earlier discussed file descriptors running out issues?

FSEvents API leaks file descriptors (KQUEUE)
https://stackoverflow.com/questions/20311184/fsevents-api-leaks-file-descriptors-kqueue <https://stackoverflow.com/questions/20311184/fsevents-api-leaks-file-descriptors-kqueue>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221116/01752a76/attachment.htm>

From pminborg at openjdk.org  Thu Nov 17 10:29:26 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 17 Nov 2022 10:29:26 GMT
Subject: RFR: 8297194: Add a @sealedGraph tag to Buffer
Message-ID: <Kf3D3FzCuY-4P3pWXGpNEEWlTGbEp2o3SWVZUHTnTcw=.a1bc22ca-39d7-4882-be6e-46f382874c0b@github.com>

This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `Buffer` class.

Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653

Here is how it would look like:

<img width="475" alt="Buffer_SH" src="https://user-images.githubusercontent.com/7457876/202420742-4d379512-1d8c-4b32-8d17-d2e70faa3a8f.png">

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

Commit messages:
 - Add a @sealedGraph tag to Reference

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

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

From alanb at openjdk.org  Thu Nov 17 10:34:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Nov 2022 10:34:20 GMT
Subject: RFR: 8297194: Add a @sealedGraph tag to Buffer
In-Reply-To: <Kf3D3FzCuY-4P3pWXGpNEEWlTGbEp2o3SWVZUHTnTcw=.a1bc22ca-39d7-4882-be6e-46f382874c0b@github.com>
References: <Kf3D3FzCuY-4P3pWXGpNEEWlTGbEp2o3SWVZUHTnTcw=.a1bc22ca-39d7-4882-be6e-46f382874c0b@github.com>
Message-ID: <NwADfHfeJ1Yw75kx7YokcJcBW_31AievIM5MP6hMbyY=.6fb8d358-eec3-4b4d-8aea-a29416b87f6e@github.com>

On Thu, 17 Nov 2022 10:21:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `Buffer` class.
> 
> Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653
> 
> Here is how it would look like:
> 
> <img width="475" alt="Buffer_SH" src="https://user-images.githubusercontent.com/7457876/202420742-4d379512-1d8c-4b32-8d17-d2e70faa3a8f.png">

Marked as reviewed by alanb (Reviewer).

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

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

From pminborg at openjdk.org  Thu Nov 17 11:49:50 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 17 Nov 2022 11:49:50 GMT
Subject: Integrated: 8297194: Add a @sealedGraph tag to Buffer
In-Reply-To: <Kf3D3FzCuY-4P3pWXGpNEEWlTGbEp2o3SWVZUHTnTcw=.a1bc22ca-39d7-4882-be6e-46f382874c0b@github.com>
References: <Kf3D3FzCuY-4P3pWXGpNEEWlTGbEp2o3SWVZUHTnTcw=.a1bc22ca-39d7-4882-be6e-46f382874c0b@github.com>
Message-ID: <j8dlSZ3Kgki9PmwPrpr2Dh_WfrRsVrStrfrP9WifaRw=.6cee6784-16e3-4abd-8724-daaafde7c895@github.com>

On Thu, 17 Nov 2022 10:21:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `Buffer` class.
> 
> Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653
> 
> Here is how it would look like:
> 
> <img width="475" alt="Buffer_SH" src="https://user-images.githubusercontent.com/7457876/202420742-4d379512-1d8c-4b32-8d17-d2e70faa3a8f.png">

This pull request has now been integrated.

Changeset: 171553a6
Author:    Per Minborg <pminborg at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/171553a61194b91eeaff68198e105327484f173e
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8297194: Add a @sealedGraph tag to Buffer

Reviewed-by: alanb

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

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

From duke at openjdk.org  Thu Nov 17 16:20:29 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 17 Nov 2022 16:20:29 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v27]
In-Reply-To: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com>
Message-ID: <HAnwHSgGBY35ThuRENIFnsNwci18giPhEYTw-di36vk=.571ad158-2381-4e15-8cd1-f87c0193f4d1@github.com>

On Tue, 15 Nov 2022 18:47:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in SegmentScope javadoc

src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 77:

> 75:         } catch (Throwable ex) {
> 76:             throw new ExceptionInInitializerError(ex);
> 77:         }

The?above `catch`?clause should?only catch?`Exception`s, not?`Throwable`s, as?the?latter would?hide VM?errors such?as?`StackOverflowError` or?`OutOfMemoryError`.

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

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

From duke at openjdk.org  Thu Nov 17 19:45:13 2022
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 17 Nov 2022 19:45:13 GMT
Subject: Integrated: 8249693:
 java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id
In-Reply-To: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
References: <XoL2ltuCbpJWoD3Qc0lqDt5XdLm47U0f8SGSPYKD7eM=.2bcf9000-aee0-4f5c-b145-9bdbe127c712@github.com>
Message-ID: <YK-aWFXHaHnnSzBEoxbuwwdcQBEY5svRlLI6Qg6afAU=.d7da2a97-bc5b-4c8c-a594-f93e89e15af3@github.com>

On Mon, 7 Nov 2022 19:13:24 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Added a check that source and destination volumes have enough space to run the test.
> 
> This test will no longer be ignored.

This pull request has now been integrated.

Changeset: 819af69f
Author:    Matthew Donovan <matthew.p.donovan at oracle.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/819af69f408261f55af883ba015c1f6179236582
Stats:     43 lines in 1 file changed: 37 ins; 1 del; 5 mod

8249693: java/nio/channels/FileChannel/FileExtensionAndMap.java uses @ignore w/o bug id

Reviewed-by: rhalade

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

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

From tsteele at openjdk.org  Fri Nov 18 21:38:11 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Fri, 18 Nov 2022 21:38:11 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes test
 failures
Message-ID: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>

This minor change fixes a compliance test failure which was partially addressed by https://github.com/openjdk/jdk/commit/1bb4de2e2868a539846ec48dd43fd623c2ba69a5. However the failure was still observed on select machines. This change addresses the remaining failures by ensuring that any new WatchKey is held until the polling thread becomes active.

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

Commit messages:
 - Add Thread.sleep to PollingWatchService's register method

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

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

From tsteele at openjdk.org  Fri Nov 18 21:38:11 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Fri, 18 Nov 2022 21:38:11 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
Message-ID: <2TFEbO9EORoHWrXqW4Z17TsA9_sOdyP5qXWLdFEn0M8=.7699b6fa-2910-44b7-b4f0-5cac60145e78@github.com>

On Fri, 21 Oct 2022 21:43:25 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> This minor change fixes a compliance test failure which was partially addressed by https://github.com/openjdk/jdk/commit/1bb4de2e2868a539846ec48dd43fd623c2ba69a5. However the failure was still observed on select machines. This change addresses the remaining failures by ensuring that any new WatchKey is held until the polling thread becomes active.

The Windows pre-test failure is related to `runtime/ParallelLoad/SuperWait/SuperWaitTest.java` and should not be related to this change. Windows as a native library based implementation and does not use the one provided by PollingWatchService.

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

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

From alanb at openjdk.org  Sat Nov 19 08:06:38 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Nov 2022 08:06:38 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
Message-ID: <bIltZWdM6AftUW4ba-ImG8_nkhjO5ov6Z0yDIvPJfDI=.01f9255b-12e4-45c4-8109-b12e73977450@github.com>

On Fri, 21 Oct 2022 21:43:25 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> This minor change fixes a compliance test failure which was partially addressed by https://github.com/openjdk/jdk/commit/1bb4de2e2868a539846ec48dd43fd623c2ba69a5. However the failure was still observed on select machines. This change addresses the remaining failures by ensuring that any new WatchKey is held until the polling thread becomes active.

This seems to adds a 1s sleep to Path.register. I don't think we want that. Would it be possible to start with a summary of the test failure that you are running into.

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

Changes requested by alanb (Reviewer).

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

From mik3hall at gmail.com  Sat Nov 19 13:13:40 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 19 Nov 2022 07:13:40 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <4D6F12D9-8D85-4A7E-A95E-AAC22FA2C5F9@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <hmqV92znlcHodK2Mow3y66X7bxOb7x3Y4oF1n4Pub40=.4657de2e-da2c-47c2-b264-ed8fe1d3635d@github.com>
 <C6F733EF-AAB0-4F29-85C5-C1E2DD0E0CF6@gmail.com>
 <4D6F12D9-8D85-4A7E-A95E-AAC22FA2C5F9@gmail.com>
Message-ID: <6D59EEF6-727B-4409-844F-1334BAE91179@gmail.com>



> On Nov 16, 2022, at 8:49 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Nov 16, 2022, at 8:44 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>> 
>>> 
>>> @AlanBateman still can't reproduce any of that on my hardware, 
>>> 
>> 
>> Same using ?make test? besides my own modified. 
>> 
>> Passed: java/nio/file/WatchService/LotsOfEvents.java
>> 
>>> I've been backed up with other things and finally getting to look at this more closely. For testing, I tried both release and debug builds across a range of macOS releases on both x64 and aarch64. Unfortunately there is a lot of timeouts and intermittent failures and across quite a range of macOS releases (from 10.15 to 12.2).
>> 
>> Doesn?t this sort of sound like a threading/deadlock type issue? Intermittent - timeouts. Maybe your runloop concerns were well founded.
> 
> Or does this possibly go back to the earlier discussed file descriptors running out issues?
> 
> FSEvents API leaks file descriptors (KQUEUE)
> https://stackoverflow.com/questions/20311184/fsevents-api-leaks-file-descriptors-kqueue <https://stackoverflow.com/questions/20311184/fsevents-api-leaks-file-descriptors-kqueue>
I changed my modified LotsOfEvents to run 20 times and saw no indication doing lsof?s that file descriptors might be leaked.

All 20 did run successfully. Are there any suggestions as to what is being done differently for the frequent errors as opposed to when there are no failures?

Again,
WatchService: Run loop 600003a5c500 - waiting for event source...
----------System.err:(12/655)----------
java.lang.RuntimeException: Key not signalled (unexpected)
	at LotsOfEvents.drainAndCheckOverflowEvents(LotsOfEvents.java:112)
	at LotsOfEvents.testOverflowEvent(LotsOfEvents.java:84)
	at LotsOfEvents.main(LotsOfEvents.java:51)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:1591)

The runloop ?appears? to go into a wait for something that doesn?t happen. I think I saw LotsOfEvents may have different timeout limits than the test framework.

WatchService: Run loop 60000
result: Error. Agent error: java.lang.Exception: Agent 8 timed out with a timeout of 480 seconds; check console log for any additional details

This one appears to be the testing framework issuing the timeout. 8 minutes seems more like a deadlock. Again following a run loop trace message.

It seems like you could look into the run loop part of the code. I never had a good grasp on run loops. 
Hoping that some change eliminates the errors. But being unable to reproduce the errors I don?t know that I would want to try this.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221119/00a0f7ce/attachment.htm>

From alanb at openjdk.org  Sat Nov 19 14:58:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Nov 2022 14:58:44 GMT
Subject: RFR: 8297293: Add
 java/nio/channels/FileChannel/FileExtensionAndMap.java to ProblemList
Message-ID: <YJF8UPoI5PXB2zKv27fIXYZoCHC3NwK4Gf33jcyeON4=.89b84ff3-91b9-4be7-9ee8-99ba289bfc7a@github.com>

java/nio/channels/FileChannel/FileExtensionAndMap.java was excluded for a long time because it required too many resources. It was re-enabled recently via JDK-8249693 but it's back causing problems again add adding up to 40 minutes to jdk/:tier2_part2. I'd like to exclude it again until the test can be re-written.

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

Commit messages:
 - Exclude FileExtensionAndMap.java

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

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

From lancea at openjdk.org  Sat Nov 19 15:04:18 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 19 Nov 2022 15:04:18 GMT
Subject: RFR: 8297293: Add
 java/nio/channels/FileChannel/FileExtensionAndMap.java to ProblemList
In-Reply-To: <YJF8UPoI5PXB2zKv27fIXYZoCHC3NwK4Gf33jcyeON4=.89b84ff3-91b9-4be7-9ee8-99ba289bfc7a@github.com>
References: <YJF8UPoI5PXB2zKv27fIXYZoCHC3NwK4Gf33jcyeON4=.89b84ff3-91b9-4be7-9ee8-99ba289bfc7a@github.com>
Message-ID: <e70A6cgS4RMte5rhTg62lrHJkM8rDA2xKHlslXHvUa0=.b480e5c5-6ede-4888-b092-0461307069e1@github.com>

On Sat, 19 Nov 2022 14:24:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> java/nio/channels/FileChannel/FileExtensionAndMap.java was excluded for a long time because it required too many resources. It was re-enabled recently via JDK-8249693 but it's back causing problems again add adding up to 40 minutes to jdk/:tier2_part2. I'd like to exclude it again until the test can be re-written.

Marked as reviewed by lancea (Reviewer).

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

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

From alanb at openjdk.org  Sat Nov 19 17:13:15 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Nov 2022 17:13:15 GMT
Subject: RFR: 8297293: Add
 java/nio/channels/FileChannel/FileExtensionAndMap.java to ProblemList
In-Reply-To: <e70A6cgS4RMte5rhTg62lrHJkM8rDA2xKHlslXHvUa0=.b480e5c5-6ede-4888-b092-0461307069e1@github.com>
References: <YJF8UPoI5PXB2zKv27fIXYZoCHC3NwK4Gf33jcyeON4=.89b84ff3-91b9-4be7-9ee8-99ba289bfc7a@github.com>
 <e70A6cgS4RMte5rhTg62lrHJkM8rDA2xKHlslXHvUa0=.b480e5c5-6ede-4888-b092-0461307069e1@github.com>
Message-ID: <HeAOaSWQU4_yVpyZT2Ir7SUktLYr5UFnpzZwZ_AvpEM=.273bb91f-354c-4ce0-8e20-cff654a5bad3@github.com>

On Sat, 19 Nov 2022 15:01:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> java/nio/channels/FileChannel/FileExtensionAndMap.java was excluded for a long time because it required too many resources. It was re-enabled recently via JDK-8249693 but it's back causing problems again add adding up to 40 minutes to jdk/:tier2_part2. I'd like to exclude it again until the test can be re-written.
>
> Marked as reviewed by lancea (Reviewer).

Thanks @LanceAndersen.

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

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

From alanb at openjdk.org  Sat Nov 19 17:15:00 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Nov 2022 17:15:00 GMT
Subject: Integrated: 8297293: Add
 java/nio/channels/FileChannel/FileExtensionAndMap.java to ProblemList
In-Reply-To: <YJF8UPoI5PXB2zKv27fIXYZoCHC3NwK4Gf33jcyeON4=.89b84ff3-91b9-4be7-9ee8-99ba289bfc7a@github.com>
References: <YJF8UPoI5PXB2zKv27fIXYZoCHC3NwK4Gf33jcyeON4=.89b84ff3-91b9-4be7-9ee8-99ba289bfc7a@github.com>
Message-ID: <zPcKUX9pgJ8dnJgqbj843H21ivSA70hR8xHndag5tLQ=.09b420c1-bca0-4f1b-9753-8b7bd268516b@github.com>

On Sat, 19 Nov 2022 14:24:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> java/nio/channels/FileChannel/FileExtensionAndMap.java was excluded for a long time because it required too many resources. It was re-enabled recently via JDK-8249693 but it's back causing problems again add adding up to 40 minutes to jdk/:tier2_part2. I'd like to exclude it again until the test can be re-written.

This pull request has now been integrated.

Changeset: 7b3d5814
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7b3d5814978dbea671985f6b3eab420431a0aca6
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8297293: Add java/nio/channels/FileChannel/FileExtensionAndMap.java to ProblemList

Reviewed-by: lancea

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

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

From pminborg at openjdk.org  Mon Nov 21 11:00:13 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 11:00:13 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
Message-ID: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>

This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 

Design choices in this PR:

There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.

The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.

In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.

On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".

I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.

This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

Commit messages:
 - Guard usages of DirectBuffer::address

Changes: https://git.openjdk.org/jdk/pull/11260/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296024
  Stats: 277 lines in 26 files changed: 191 ins; 4 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From alanb at openjdk.org  Mon Nov 21 11:31:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 11:31:16 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>

On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

src/java.base/share/classes/java/nio/Buffer.java line 785:

> 783:                 static final JavaNioAccess.SessionAcquisition NO_OP_CLOSE = new JavaNioAccess.SessionAcquisition() {
> 784:                     @Override
> 785:                     public void close() throws RuntimeException {}

The throws RuntimeException is not needed here. Also would it be possible to reflow the comment to avoid the wildly long line.

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 161:

> 159: 
> 160:         @Override
> 161:         void close() throws RuntimeException;

You can drop throws RuntimeEXcepton here too.

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 38:

> 36:     // try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {
> 37:     //     performOperation(bb.address());
> 38:     // }

This comment is very messy and needs to be cleaned up.

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252:

> 250:         try {
> 251:             // 'dst' is guaranteed not to be associated with a closeable session.
> 252:             // Hence, there is no need for acquiring any session.

This comment is will be confusing to anyone reading this code. Is this really needed?

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

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

From alanb at openjdk.org  Mon Nov 21 11:36:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 11:36:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>

On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

src/java.base/share/classes/java/util/zip/Adler32.java line 102:

> 100:             return;
> 101:         if (buffer.isDirect()) {
> 102:             try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) {

We need to find something better than "sessionAcquisition", it looks very messy at all these use sites.

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

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

From pminborg at openjdk.org  Mon Nov 21 11:40:23 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 11:40:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
Message-ID: <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>

On Mon, 21 Nov 2022 11:29:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252:
> 
>> 250:         try {
>> 251:             // 'dst' is guaranteed not to be associated with a closeable session.
>> 252:             // Hence, there is no need for acquiring any session.
> 
> This comment is will be confusing to anyone reading this code. Is this really needed?

The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them.

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

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

From pminborg at openjdk.org  Mon Nov 21 12:09:20 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:09:20 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
Message-ID: <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>

On Mon, 21 Nov 2022 11:32:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> src/java.base/share/classes/java/util/zip/Adler32.java line 102:
> 
>> 100:             return;
>> 101:         if (buffer.isDirect()) {
>> 102:             try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) {
> 
> We need to find something better than "sessionAcquisition", it looks very messy at all these use sites.

Eventually, I hope most of them will be named `_`.

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

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

From alanb at openjdk.org  Mon Nov 21 12:09:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 12:09:20 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
In-Reply-To: <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
 <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>
Message-ID: <vX9B3xTKhzAl3uVrWSkyiyH9NkMjzG4ry3gcCLdvTzo=.20b0b3b4-8020-4844-a05c-358090533806@github.com>

On Mon, 21 Nov 2022 11:36:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252:
>> 
>>> 250:         try {
>>> 251:             // 'dst' is guaranteed not to be associated with a closeable session.
>>> 252:             // Hence, there is no need for acquiring any session.
>> 
>> This comment is will be confusing to anyone reading this code. Is this really needed?
>
> The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them.

I'd prefer to see this comment removed from all places that are obviously interacting with the direct buffer cache. These usages are try-finally to acquire and return the temporary direct buffer cache back to the cache. Talking about closable sessions here is definitely confusing.

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

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

From pminborg at openjdk.org  Mon Nov 21 12:20:01 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:20:01 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v2]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <IdvkKlVEKF8ztjOHvgSwd3z2aJLRJtbUA-2P4H4A42Y=.faab2987-1d1d-4f4f-82df-f9f8db576caf@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code.
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Cleanup after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/23a6fd14..9fafafac

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

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

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

From mcimadamore at openjdk.org  Mon Nov 21 12:20:05 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Nov 2022 12:20:05 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v2]
In-Reply-To: <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
Message-ID: <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>

On Mon, 21 Nov 2022 12:03:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/Adler32.java line 102:
>> 
>>> 100:             return;
>>> 101:         if (buffer.isDirect()) {
>>> 102:             try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) {
>> 
>> We need to find something better than "sessionAcquisition", it looks very messy at all these use sites.
>
> Eventually, I hope most of them will be named `_`.

maybe just `bufferLock` and and just `acquireBuffer` ?

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

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

From alanb at openjdk.org  Mon Nov 21 12:21:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 12:21:56 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v2]
In-Reply-To: <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
 <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
Message-ID: <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>

On Mon, 21 Nov 2022 12:16:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Eventually, I hope most of them will be named `_`.
>
> maybe just `bufferLock` and and just `acquireBuffer` ?

Would it be possible to re-examine acquireSession returning Runnable and 
acquireSessionAsAutoCloseable returning AutoCloseable. The naming is awkward at most of the use sites and maybe we can do better.

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

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

From pminborg at openjdk.org  Mon Nov 21 12:37:33 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:37:33 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v3]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <hhDVmcADk7zrfplELPNulJjOm0n56IKFmBE8Dmr2K4w=.d4f2ee38-2199-4323-85f7-b840e084904c@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Remove comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/9fafafac..9fcf2bb3

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

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

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

From pminborg at openjdk.org  Mon Nov 21 12:54:17 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 12:54:17 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v3]
In-Reply-To: <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
 <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
 <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>
Message-ID: <f3NwWq8NYpYSuL_pcM8dOa7G1k3XP0as_URwhgKaRR8=.471a5885-b228-434c-a2f5-539610643c07@github.com>

On Mon, 21 Nov 2022 12:19:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> maybe just `bufferLock` and and just `acquireBuffer` ?
>
> Would it be possible to re-examine acquireSession returning Runnable and 
> acquireSessionAsAutoCloseable returning AutoCloseable. The naming is bit awkward at most of the use sites and maybe we can do better.

I think it would be confusing to have overloads with the same name. 

The `aquireSession(Buffer, boolean)` method is only used once and is used in `IOUtil` so we could rename it to `aquireSessionOrNull` and then rename `acquireSessionAsAutoCloseable` to `acquireSession`.

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

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

From pminborg at openjdk.org  Mon Nov 21 13:02:48 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 13:02:48 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Rename methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/9fcf2bb3..c081b4ae

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

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

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

From duke at openjdk.org  Mon Nov 21 13:39:23 2022
From: duke at openjdk.org (ExE Boss)
Date: Mon, 21 Nov 2022 13:39:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
Message-ID: <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>

On Mon, 21 Nov 2022 13:02:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename methods

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 94:

> 92:      * required to guarantee safety.
> 93:      * {@snippet lang = java:
> 94:      * var handler = acquireSessionOrNoOp(buffer);

Suggestion:

     * var handler = acquireSessionOrNull(buffer, async);

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41:

> 39:     // An example of a guarded use of a memory address is shown here:
> 40:     //
> 41:     // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {

Suggestion:

    // try (var guard = NIO_ACCESS.acquireSession(bb)) {

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

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

From pminborg at openjdk.org  Mon Nov 21 13:43:21 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 13:43:21 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v5]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <iECO8UBKUoYcWn5I67E9kbCsy4tLqdswYhddUllpcLQ=.494414bf-1401-4e40-bc14-4f86f60b335e@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Cleanup static declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/c081b4ae..eca7c388

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

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

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

From pminborg at openjdk.org  Mon Nov 21 13:49:09 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 13:49:09 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>
Message-ID: <pjDWu8PP_Y2gF3Xn-LtjHKL4L3wm8heNF7W1QL9CKsQ=.1e748c4e-5081-4019-ad83-559dae7f4ec5@github.com>

On Mon, 21 Nov 2022 13:32:43 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename methods
>
> src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41:
> 
>> 39:     // An example of a guarded use of a memory address is shown here:
>> 40:     //
>> 41:     // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {
> 
> Suggestion:
> 
>     // try (var guard = NIO_ACCESS.acquireSession(bb)) {

Are you happy with the proposed renaming now @ExE-Boss ? I think our propositions crossed in time?

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

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

From duke at openjdk.org  Mon Nov 21 13:49:09 2022
From: duke at openjdk.org (ExE Boss)
Date: Mon, 21 Nov 2022 13:49:09 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <pjDWu8PP_Y2gF3Xn-LtjHKL4L3wm8heNF7W1QL9CKsQ=.1e748c4e-5081-4019-ad83-559dae7f4ec5@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <Ba_lSOfMvOVeHMycVnOiE9SP0wwB3hoaCrWH6HQhhsY=.18d61e83-fcd9-4d20-b75a-424374eab446@github.com>
 <pjDWu8PP_Y2gF3Xn-LtjHKL4L3wm8heNF7W1QL9CKsQ=.1e748c4e-5081-4019-ad83-559dae7f4ec5@github.com>
Message-ID: <UQL92ereV30YE4RxJFFHfF8YQFznI0les962qyQjsT4=.6123ea57-7532-41c3-a8d6-b00282d4fa3b@github.com>

On Mon, 21 Nov 2022 13:43:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41:
>> 
>>> 39:     // An example of a guarded use of a memory address is shown here:
>>> 40:     //
>>> 41:     // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) {
>> 
>> Suggestion:
>> 
>>     // try (var guard = NIO_ACCESS.acquireSession(bb)) {
>
> Are you happy with the proposed renaming now @ExE-Boss ? I think our propositions crossed in time?

This?change was?missed in?commit?<https://github.com/openjdk/jdk/pull/11260/commits/c081b4aebb7b52c7161656b4cba9b0a60d36202a>.

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

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

From pminborg at openjdk.org  Mon Nov 21 14:02:38 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 14:02:38 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

 - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/eca7c388..a0de3bcf

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

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

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

From pminborg at openjdk.org  Mon Nov 21 14:06:08 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 14:06:08 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v7]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <85JCc27fZGJjTrQbm1vJfA6BY1KgAZ9PLlRJQgbcj3M=.1707b29d-4c0c-4f0f-9be9-acbfc341d571@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

Per Minborg has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains six commits:

 - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Cleanup static declarations
 - Rename methods
 - Remove comments
 - Cleanup after comments
 - Guard usages of DirectBuffer::address

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/a0de3bcf..17a72e9f

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

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

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

From alanb at openjdk.org  Mon Nov 21 14:11:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 14:11:31 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
Message-ID: <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>

On Mon, 21 Nov 2022 13:02:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename methods

src/java.base/share/classes/java/util/zip/Adler32.java line 105:

> 103:                 adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem);
> 104:             } finally {
> 105:                 Reference.reachabilityFence(buffer);

The updated naming is a bit better but there are it still feels that that there are too many things going on at the use sites ("guard", "session", "reachability fence"). Ideally the acquire would return something with an accessor for the direct buffer address but that may not be possible.  I wonder if changing NOP_CLOSE.close to do reachabilityFence(this) would work as expected and improve many of these use sites?

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

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

From alanb at openjdk.org  Mon Nov 21 14:16:41 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 14:16:41 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
Message-ID: <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>

On Mon, 21 Nov 2022 14:02:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/java.base/share/classes/sun/nio/fs/NativeBuffers.java line 92:

> 90:      * allocated from the heap.
> 91:      * <p>
> 92:      * The returned NativeBuffer is guaranteed not to be asynchronously closeable.

This class, and the temporary buffer cache in sun.nio.ch.Util, are intended to be used with try-finally. There isn't any notion of  asynchronously close so maybe it would best to not add this comment to these sources.

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

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

From mkartashev at openjdk.org  Mon Nov 21 14:21:36 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Mon, 21 Nov 2022 14:21:36 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <vK98Lx7Y5Z9zH6ag4bSmnjZoKBBsJ_NwfEFogZGW8Uo=.202b0824-938f-4e2b-9694-53c6e9b433dc@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <vK98Lx7Y5Z9zH6ag4bSmnjZoKBBsJ_NwfEFogZGW8Uo=.202b0824-938f-4e2b-9694-53c6e9b433dc@github.com>
Message-ID: <NiWCA6dzdzYtFJjN2z7s40yQESN7Wyyh_y2-Bp3bQQg=.0f23fa8c-006e-40d4-9de8-491375ee0172@github.com>

On Wed, 16 Nov 2022 08:11:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> In our CI system `test/jdk/java/nio/file/WatchService/Move.java` appears to time out consistently, although I have not seen it happen on my local machine.
>> 
>> I've been backed up with other things and finally getting to look at this more closely. For testing, I tried both release and debug builds across a range of macOS releases on both x64 and aarch64. Unfortunately there is a lot of timeouts and intermittent failures and across quite a range of macOS releases (from 10.15 to 12.2).
>> 
>> The most frequent failure seems to be the testOverflowEvent test in LotsOfEvents.  Here's an example failure:
>> 
>> ----------System.out:(1/47)----------
>> Seed from RandomFactory = 1932318894124342221L
>> ----------System.err:(12/655)----------
>> java.lang.RuntimeException: Key not signalled (unexpected)
>> 	at LotsOfEvents.drainAndCheckOverflowEvents(LotsOfEvents.java:105)
>> 	at LotsOfEvents.testOverflowEvent(LotsOfEvents.java:78)
>> 	at LotsOfEvents.main(LotsOfEvents.java:51)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>> 	at java.base/java.lang.Thread.run(Thread.java:1591)
>
>> @AlanBateman still can't reproduce any of that on my hardware, so I added some tracing so that next time tests are run we can at least see what's happening.
> 
> LotsOfEvents.java on macOS 12.2
> 
> ----------stdout:(7/337)----------
> WatchService: get run loop -> 600003a5c500
> WatchService: running run loop 600003a5c500
> WatchService: created event stream 101105150
> WatchService: scheduled event stream 101105150 on run loop 600003a5c500
> WatchService: running run loop 600003a5c500
> WatchService: stopped event stream 101105150
> WatchService: stopped run loop 600003a5c500
> ----------System.out:(10/421)----------
> Seed from RandomFactory = 5027502271796047304L
> WatchService: Run loop 600003a5c500 - waiting...
> WatchService: Run loop 600003a5c500 - starting...
> Test: dir.register - start
> WatchService: Run loop 600003a5c500 - waiting for event source...
> Test: dir.register - done
> WatchService: Run loop 600003a5c500 - starting...
> Test: created files
> Test: About to poll
> WatchService: Run loop 600003a5c500 - waiting for event source...
> ----------System.err:(12/655)----------
> java.lang.RuntimeException: Key not signalled (unexpected)
> 	at LotsOfEvents.drainAndCheckOverflowEvents(LotsOfEvents.java:112)
> 	at LotsOfEvents.testOverflowEvent(LotsOfEvents.java:84)
> 	at LotsOfEvents.main(LotsOfEvents.java:51)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:1591)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException
> JavaTest Message: shutting down test
> 
> result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Key not signalled (unexpected)
> 
> 
> DeleteInterference.java also  on macOS 12.2, this one is a timeout:
> 
> open 292 end
> open 293 begin
> WatchService: Run loop 6000004a9000 - waiting...
> WatchService: Run loop 6000004a9000 - starting...
> WatchService: Run loop 6000004a9000 - waiting for event source...
> open 293 end
> open 294 begin
> WatchService: Run loop 6000004ade00 - waiting...
> WatchService: Run loop 6000004ade00 - starting...
> WatchService: Run loop 6000004ade00 - waiting for event source...
> WatchService: Run loop 6000004ade00 - starting...
> WatchService: Run loop 60000
> result: Error. Agent error: java.lang.Exception: Agent 8 timed out with a timeout of 480 seconds; check console log for any additional details
> 
> test result: Error. Agent error: java.lang.Exception: Agent 8 timed out with a timeout of 480 seconds; check console log for any additional details
> 
> 
> The .jtr are huge due to all the tracing.

@AlanBateman Thank you for the log. I see all the right calls, but I don't see any events coming in from the OS.

I'm afraid this is the line beyond which I can't tread; there seem to be instances where [certain directories don't generate FSEvents](https://github.com/livereload/livereload-site/blob/master/livereload.com/_articles/troubleshooting/os-x-fsevents-bug-may-prevent-monitoring-of-certain-folders.md), there's even a [tool](https://github.com/andreyvit/find-fsevents-bugs) to find those. Unfortunately, I know nothing beyond what was said on those pages.

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

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

From mik3hall at gmail.com  Mon Nov 21 14:51:04 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 21 Nov 2022 08:51:04 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <NiWCA6dzdzYtFJjN2z7s40yQESN7Wyyh_y2-Bp3bQQg=.0f23fa8c-006e-40d4-9de8-491375ee0172@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <vK98Lx7Y5Z9zH6ag4bSmnjZoKBBsJ_NwfEFogZGW8Uo=.202b0824-938f-4e2b-9694-53c6e9b433dc@github.com>
 <NiWCA6dzdzYtFJjN2z7s40yQESN7Wyyh_y2-Bp3bQQg=.0f23fa8c-006e-40d4-9de8-491375ee0172@github.com>
Message-ID: <0A744585-8DC1-4350-A560-049060986206@gmail.com>



>> 
>> 
> 
> @AlanBateman Thank you for the log. I see all the right calls, but I don't see any events coming in from the OS.
> 
> I'm afraid this is the line beyond which I can't tread; there seem to be instances where [certain directories don't generate FSEvents](https://github.com/livereload/livereload-site/blob/master/livereload.com/_articles/troubleshooting/os-x-fsevents-bug-may-prevent-monitoring-of-certain-folders.md <https://github.com/livereload/livereload-site/blob/master/livereload.com/_articles/troubleshooting/os-x-fsevents-bug-may-prevent-monitoring-of-certain-folders.md>), there's even a [tool](https://github.com/andreyvit/find-fsevents-bugs <https://github.com/andreyvit/find-fsevents-bugs>) to find those. Unfortunately, I know nothing beyond what was said on those pages.
> 

If as these suggest this is an Apple FSEvents bug it might be worth filing your own bug report? I?m don?t remember what Apple does with duplicates but they may not close yours and you could get updates.

For me this still continues to run flawlessly. I haven?t been able to break it trying. So the property might still make sense for some users?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221121/a4f697c2/attachment-0001.htm>

From pminborg at openjdk.org  Mon Nov 21 15:31:32 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 15:31:32 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
 <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>
Message-ID: <Z7OKBFBHqPQDCnjhLlZgL4wM-FmmPpTiBr7pp3T-KZU=.2f965b13-a689-482b-9bfd-46d9efcac70c@github.com>

On Mon, 21 Nov 2022 14:14:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/java.base/share/classes/sun/nio/fs/NativeBuffers.java line 92:
> 
>> 90:      * allocated from the heap.
>> 91:      * <p>
>> 92:      * The returned NativeBuffer is guaranteed not to be asynchronously closeable.
> 
> This class, and the temporary buffer cache in sun.nio.ch.Util, are intended to be used with try-finally. There isn't any notion of  asynchronously close so maybe it would best to not add this comment to these sources.

That is clear to me but I am trying to prevent future redundant guarding. Anyway, I will remove the comments.

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

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

From pminborg at openjdk.org  Mon Nov 21 15:34:54 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 15:34:54 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v8]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <wajuJrHs8kgD4SezHUCBWvAceHqa5YSY2olr7QPLSms=.42f6db8c-23bf-486d-97d4-0ebaac18f7e1@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

 - Merge branch 'guard-directbuffer-address' of https://github.com/minborg/jdk into guard-directbuffer-address
 - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Remove comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/17a72e9f..88ed3aa2

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

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

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

From pminborg at openjdk.org  Mon Nov 21 16:10:27 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Nov 2022 16:10:27 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
Message-ID: <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>

On Mon, 21 Nov 2022 14:07:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename methods
>
> src/java.base/share/classes/java/util/zip/Adler32.java line 105:
> 
>> 103:                 adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem);
>> 104:             } finally {
>> 105:                 Reference.reachabilityFence(buffer);
> 
> The updated naming is a bit better but there are it still feels that that there are too many things going on at the use sites ("guard", "session", "reachability fence"). Ideally the acquire would return something with an accessor for the direct buffer address but that may not be possible.  I wonder if changing NOP_CLOSE.close to do reachabilityFence(this) would work as expected and improve many of these use sites?

This can certainly be done. We could, for example, add a new method to the `JavaNioAccess` interface:

```AddressAcquisition acquireSession2(Buffer buffer); // to be renamed```

This would allow us to go from:


            try (var guard = NIO_ACCESS.acquireSession(buffer)) {
                adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem);
            } finally {
                Reference.reachabilityFence(buffer);
            }


to


            try (var guard = NIO_ACCESS.acquireSession2(buffer)) {
                adler = updateByteBuffer(adler, guard.address(), pos, rem);
            }


Although this looks much simpler and concise, it means "a new object is created for each invocation" (*). This also allows us to remove the `@SupressWarnings("try")` annotations.

Here is how the undercarriage might look like:


                @Override
                public AddressAcquisition acquireSession2(Buffer buffer) {
                    var session = buffer.session();
                    if (session == null) {
                        return AddressAcquisition.create(buffer, () -> {});
                    }
                    session.acquire0();
                    return AddressAcquisition.create(buffer, session::release0);
                }



and


sealed interface AddressAcquisition extends AutoCloseable {

        long address();

        @Override
        void close();

        static AddressAcquisition create(Buffer buffer, Runnable closeActions) {
            return new AddressAcquisitionImpl(buffer, closeActions);
        }

        final class AddressAcquisitionImpl implements AddressAcquisition {

            private final DirectBuffer directBuffer;
            private final Runnable closeAction;

            public AddressAcquisitionImpl(Buffer buffer,
                                          Runnable closeAction) {
                this.directBuffer = (DirectBuffer) buffer;
                this.closeAction = closeAction;
            }

            @Override
            public long address() {
                return directBuffer.address();
            }

            @Override
            public void close() {
                try {
                    closeAction.run();
                } finally {
                    Reference.reachabilityFence(directBuffer);
                }
            }
        }

    }



(*) In reality,  a representation of the object might be allocated on the stack instead.

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

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

From alanb at openjdk.org  Mon Nov 21 16:37:33 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 16:37:33 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
Message-ID: <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>

On Mon, 21 Nov 2022 16:08:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Although this looks much simpler and concise, it means "a new object is created for each invocation" 

My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case.  Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.

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

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

From mcimadamore at openjdk.org  Mon Nov 21 17:05:38 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Nov 2022 17:05:38 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v8]
In-Reply-To: <f3NwWq8NYpYSuL_pcM8dOa7G1k3XP0as_URwhgKaRR8=.471a5885-b228-434c-a2f5-539610643c07@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <SNwWN7HBKT2EyKgJc7q6mBCv0VcVJlnHmPdCZEco1Sc=.6e3cb1bf-d26a-4f9f-a970-1f624a5ca93d@github.com>
 <X93UidGVNmFwVEcd0D0-tngf_0M4zUahR2jd5G1ECGo=.ddfa612b-4a0b-44de-a188-f950d337772e@github.com>
 <Q_7PjWKrdO5RNq0u8IBrHgKEjx1FzrW2pny1lOYD_90=.a9e51da2-707e-427e-be41-8145445851d5@github.com>
 <QJARqApJwfn6SMwbjB4bxwo9il4owDHnVMuPmD5SyUc=.854e71c9-2986-4b19-a075-b599a3b414c2@github.com>
 <f3NwWq8NYpYSuL_pcM8dOa7G1k3XP0as_URwhgKaRR8=.471a5885-b228-434c-a2f5-539610643c07@github.com>
Message-ID: <GtZ7D3vC5YXHj_8J1pOlB7FceWDEWD4FiSvBB-cLqAI=.00dc532b-de35-4766-8d9b-abd9102246e6@github.com>

On Mon, 21 Nov 2022 12:50:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Would it be possible to re-examine acquireSession returning Runnable and 
>> acquireSessionAsAutoCloseable returning AutoCloseable. The naming is bit awkward at most of the use sites and maybe we can do better.
>
> I think it would be confusing to have overloads with the same name. 
> 
> The `aquireSession(Buffer, boolean)` method is only used once and is used in `IOUtil` so we could rename it to `aquireSessionOrNull` and then rename `acquireSessionAsAutoCloseable` to `acquireSession`.

IIRC, Runnable was chosen back then because of the issues with using TWR which was generating warnings (because resource not accessed in body of TWR). I don't have strong opinions on this, other than we should only have one way to do things, rather than 2-3. Since the JDK has capabilities to acquire and release a session w/o a TWR and/or Runnable, one might also consider whether exposing acquire/release separately, and just use those.

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

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

From mcimadamore at openjdk.org  Mon Nov 21 17:05:38 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Nov 2022 17:05:38 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
 <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
Message-ID: <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>

On Mon, 21 Nov 2022 16:34:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Although this looks much simpler and concise, it means "a new object is created for each invocation"
> 
> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.

Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths.

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

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

From tsteele at openjdk.org  Mon Nov 21 18:14:18 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Mon, 21 Nov 2022 18:14:18 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <bIltZWdM6AftUW4ba-ImG8_nkhjO5ov6Z0yDIvPJfDI=.01f9255b-12e4-45c4-8109-b12e73977450@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
 <bIltZWdM6AftUW4ba-ImG8_nkhjO5ov6Z0yDIvPJfDI=.01f9255b-12e4-45c4-8109-b12e73977450@github.com>
Message-ID: <J9sQXv1jHfOe7pVTjEfq9R3aVZLz-OHZFEIj0-EMLh8=.c76b04ff-9757-43ba-8d96-1debcde30f78@github.com>

On Sat, 19 Nov 2022 08:04:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This minor change fixes a compliance test failure which was partially addressed by https://github.com/openjdk/jdk/commit/1bb4de2e2868a539846ec48dd43fd623c2ba69a5. However the failure was still observed on select machines. This change addresses the remaining failures by ensuring that any new WatchKey is held until the polling thread becomes active.
>
> This seems to adds a 1s sleep to Path.register. I don't think we want that. Would it be possible to start with a summary of the test failure that you are running into.

Hi @AlanBateman, thanks for your interest in the PR :slightly_smiling_face: 

> Would it be possible to start with a summary of the test failure that you are running into

The WatchService test I am debugging, creates a WatchKey and expects it to notice changes that the test makes to the file system. On AIX, this test is timing out after 10s without seeing the changes. My first PR to address this issue [1] changed the delay between when the polling thread is created, and when it begins polling for changes. That fix addressed the changes on IBM's internal servers. However, the issue still occurs on Adoptium servers.

The delay proposed by this PR, ensures that the WatchKey polling thread is active before returning the WatchKey via the register method. I agree that it's not really ideal to add a delay to the registration process, so other suggestions are welcome.

One alternative idea might be to simply lower the POLLING_INIT_DELAY to 0. 

[1] https://github.com/openjdk/jdk/pull/8479

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

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

From alanb at openjdk.org  Mon Nov 21 19:25:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 19:25:22 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <J9sQXv1jHfOe7pVTjEfq9R3aVZLz-OHZFEIj0-EMLh8=.c76b04ff-9757-43ba-8d96-1debcde30f78@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
 <bIltZWdM6AftUW4ba-ImG8_nkhjO5ov6Z0yDIvPJfDI=.01f9255b-12e4-45c4-8109-b12e73977450@github.com>
 <J9sQXv1jHfOe7pVTjEfq9R3aVZLz-OHZFEIj0-EMLh8=.c76b04ff-9757-43ba-8d96-1debcde30f78@github.com>
Message-ID: <26KxEu6cd8zCNejvFU0FkVH7ivaP_IrFMbhAndv9QsM=.26ae3caa-483c-4483-b4c2-dc25f6851297@github.com>

On Mon, 21 Nov 2022 18:10:31 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> The WatchService test I am debugging, creates a WatchKey and expects it to notice changes that the test makes to the file system. On AIX, this test is timing out after 10s without seeing the changes. 

I wonder if this is a test issue. If the test were to use a timeout of say 60s, would it pass?

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

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

From alanb at openjdk.org  Mon Nov 21 20:08:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Nov 2022 20:08:22 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
 <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
 <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>
Message-ID: <IYL58AMPKSxquUM5jewv2kQEx9q0UcnQuCNVs8rWmro=.fb03f621-e5fd-4d64-86f9-64b648a6bb9f@github.com>

On Mon, 21 Nov 2022 17:00:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Although this looks much simpler and concise, it means "a new object is created for each invocation" 
>> 
>> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case.  Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.
>
>> > Although this looks much simpler and concise, it means "a new object is created for each invocation"
>> 
>> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.
> 
> Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths.

Right, I didn't mean BB <: AC but to see if we avoid needing to wrap it because this PR is touching several low level and performance critical code paths. For the faraway places then having the close do a Reference.reachabilityFence(this) should avoid the surprise that the buffer has to kept alive even though it appears that the try-with-resources is doing it already.

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

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

From mcimadamore at openjdk.org  Mon Nov 21 21:56:01 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Nov 2022 21:56:01 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v28]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <0y8JsbYwjCSOwW3GHC-7W3u4__AjjxlyQ_GZHR1YBtk=.f17cdd0e-652b-4906-a9a3-bf53e3d4768a@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

 - Address more review comments
 - Fix bad @throws in MemorySegment::copy methods
 - Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/876587c3..a0cee7b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=26-27

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

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

From tsteele at openjdk.org  Mon Nov 21 22:03:22 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Mon, 21 Nov 2022 22:03:22 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
Message-ID: <JcgCdi8lG4lNawnxDnQsckNyL6ZDSeMTCnaFTFh2REA=.b09f1aa1-873e-48dc-97cb-77cfa9d17539@github.com>

On Fri, 21 Oct 2022 21:43:25 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> This minor change fixes a compliance test failure which was partially addressed by https://github.com/openjdk/jdk/commit/1bb4de2e2868a539846ec48dd43fd623c2ba69a5. However the failure was still observed on select machines. This change addresses the remaining failures by ensuring that any new WatchKey is held until the polling thread becomes active.

This is another possible solution. I wanted to err on the side of the failure being valid. Once the call to `register()` completes, I think it's fair to expect that the WatchKey is active.

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

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

From maxim.kartashev at jetbrains.com  Tue Nov 22 07:46:24 2022
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Tue, 22 Nov 2022 10:46:24 +0300
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <0A744585-8DC1-4350-A560-049060986206@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <vK98Lx7Y5Z9zH6ag4bSmnjZoKBBsJ_NwfEFogZGW8Uo=.202b0824-938f-4e2b-9694-53c6e9b433dc@github.com>
 <NiWCA6dzdzYtFJjN2z7s40yQESN7Wyyh_y2-Bp3bQQg=.0f23fa8c-006e-40d4-9de8-491375ee0172@github.com>
 <0A744585-8DC1-4350-A560-049060986206@gmail.com>
Message-ID: <CAG0Tb0i4kuJ0bgxXi1_X7Joz5K-ZGPeJ8jpMFA0+XubdsTJisg@mail.gmail.com>

On Mon, Nov 21, 2022 at 5:52 PM Michael Hall <mik3hall at gmail.com> wrote:

>
> For me this still continues to run flawlessly. I haven?t been able to
> break it trying. So the property might still make sense for some users?
>
> I imagine it would, except that I can't figure out how to marry this
option with tests failing ever so often. If we run tests without that
option, it means that the code is never tested. If we run them with the
option, those will fail *occasionally*, making the whole test run appear
unreliable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221122/2e3e454e/attachment-0001.htm>

From mik3hall at gmail.com  Tue Nov 22 08:27:20 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 22 Nov 2022 02:27:20 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <CAG0Tb0i4kuJ0bgxXi1_X7Joz5K-ZGPeJ8jpMFA0+XubdsTJisg@mail.gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <vK98Lx7Y5Z9zH6ag4bSmnjZoKBBsJ_NwfEFogZGW8Uo=.202b0824-938f-4e2b-9694-53c6e9b433dc@github.com>
 <NiWCA6dzdzYtFJjN2z7s40yQESN7Wyyh_y2-Bp3bQQg=.0f23fa8c-006e-40d4-9de8-491375ee0172@github.com>
 <0A744585-8DC1-4350-A560-049060986206@gmail.com>
 <CAG0Tb0i4kuJ0bgxXi1_X7Joz5K-ZGPeJ8jpMFA0+XubdsTJisg@mail.gmail.com>
Message-ID: <CA7603E9-4DCE-4A08-8DEB-0462CF561486@gmail.com>



> On Nov 22, 2022, at 1:46 AM, Maxim Kartashev <maxim.kartashev at jetbrains.com> wrote:
> 
> 
> 
> On Mon, Nov 21, 2022 at 5:52 PM Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
> 
> For me this still continues to run flawlessly. I haven?t been able to break it trying. So the property might still make sense for some users?
> 
> I imagine it would, except that I can't figure out how to marry this option with tests failing ever so often. If we run tests without that option, it means that the code is never tested. If we run them with the option, those will fail *occasionally*, making the whole test run appear unreliable. 

For now the option would probably have to be off for testing. Assuming it?s a bug that Apple is working on. Have you tried filing to see what they say?
Possibly the jdk won?t allow having untested code included, then if you don?t expect the bug to be fixed soon you might want to provide the watch service as a 3rd party one somehow such as on GitHub.
Obviously not as good as having the jdk itself provide it, and you might want to include caveats that it sometimes has shown issues. 
But there seemed to be situations where it?s use might have advantages over polling, for what testing I?ve done it has run successfully and I would guess there would be some interest.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221122/867d9aae/attachment.htm>

From alanb at openjdk.org  Tue Nov 22 08:45:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Nov 2022 08:45:34 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <JcgCdi8lG4lNawnxDnQsckNyL6ZDSeMTCnaFTFh2REA=.b09f1aa1-873e-48dc-97cb-77cfa9d17539@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
 <JcgCdi8lG4lNawnxDnQsckNyL6ZDSeMTCnaFTFh2REA=.b09f1aa1-873e-48dc-97cb-77cfa9d17539@github.com>
Message-ID: <iRGvohC3UUeYpXHYZ3J24DIvYVaf_ZRGIyQJcZsm16k=.d06c956f-da63-4238-ae3f-edfcc17f0d1c@github.com>

On Mon, 21 Nov 2022 22:01:05 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> This is another possible solution. I wanted to err on the side of the failure being valid. Once the call to `register()` completes, I think it's fair to expect that the WatchKey is active.

I think you mean "valid" rather than "active". When you register a directory with a WatchService then it will valid (isValid method) until the key is cancelled or the WatchService is closed.

I think you'll need to paste in a reproducer or at least outline what the test does in other to make progress. Adding a 1s delay to Path.register to make a test pass just doesn't make sense. If the issue is AIX specific then maybe you can say something about the file system and the granularity of the file modification time. The polling WatchService works by polling the file modification time and maybe the issue is that it's not being updated on these systems?

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

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

From pminborg at openjdk.org  Tue Nov 22 09:11:44 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 09:11:44 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Rework Acquisition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/88ed3aa2..0526e3dc

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

  Stats: 249 lines in 19 files changed: 66 ins; 91 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From pminborg at openjdk.org  Tue Nov 22 09:11:44 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 09:11:44 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v4]
In-Reply-To: <IYL58AMPKSxquUM5jewv2kQEx9q0UcnQuCNVs8rWmro=.fb03f621-e5fd-4d64-86f9-64b648a6bb9f@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com>
 <S20FfFRYO-Oe5er8rJdRkwrZWdr_VZqMzBYJ_3yd654=.a1daa87c-e0c5-463c-b474-a1e9b492d05a@github.com>
 <N5GvHWciaOJg1w1AMkm5U9eAO9gYheccDEm3uDSykhE=.7b3ba83d-aa13-4a41-adb1-92f4b06ec7b7@github.com>
 <hw42Jr_llb2bo9tUMd8_EOqzAIJmV6zuVVhhBfysTA8=.56e14127-08f9-4303-ba7f-5212b164bad0@github.com>
 <fqDj6XbaC3ib6qW465oTnORilH-4A2XraYQE_pANddI=.ead025fa-fdc3-4803-b3e9-0f1223c7b575@github.com>
 <IYL58AMPKSxquUM5jewv2kQEx9q0UcnQuCNVs8rWmro=.fb03f621-e5fd-4d64-86f9-64b648a6bb9f@github.com>
Message-ID: <LI4GrAv6ZiaCaopZaAhzdzyCpchKYlV43-0W0aObAeU=.020fac2b-6e3d-4911-9f5a-13673f9ce7b0@github.com>

On Mon, 21 Nov 2022 20:06:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > Although this looks much simpler and concise, it means "a new object is created for each invocation"
>>> 
>>> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites.
>> 
>> Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths.
>
> Right, I didn't mean BB <: AC but to see if we avoid needing to wrap it because this PR is touching several low level and performance critical code paths. For the faraway places then having the close do a Reference.reachabilityFence(this) should avoid the surprise that the buffer has to kept alive even though it appears that the try-with-resources is doing it already.

I have reworked Acquisition. I think we could merge the old and new way in a separate PR.

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

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

From alanb at openjdk.org  Tue Nov 22 09:34:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Nov 2022 09:34:36 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v6]
In-Reply-To: <Z7OKBFBHqPQDCnjhLlZgL4wM-FmmPpTiBr7pp3T-KZU=.2f965b13-a689-482b-9bfd-46d9efcac70c@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <RiHjp4UogWljpBbU-DOwKMp8fPufxLu6UGghJ8o1iGg=.a8794224-0faf-40b5-b9f6-f4f235c9b838@github.com>
 <JtRAy-ZlC9R_w6oIxEkObI_c7XvhlY2elRnkWXs1_wE=.177b7538-e6d8-4059-82bb-3f9c72f1e663@github.com>
 <Z7OKBFBHqPQDCnjhLlZgL4wM-FmmPpTiBr7pp3T-KZU=.2f965b13-a689-482b-9bfd-46d9efcac70c@github.com>
Message-ID: <CHWjD0UP6P-l-JvOzxkaosyV6qcfXEtjPwpgSVDz2PU=.7c420616-8bc4-43de-8e32-91d2f1d4d0ff@github.com>

On Mon, 21 Nov 2022 15:29:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> That is clear to me but I am trying to prevent future redundant guarding. Anyway, I will remove the comments.

The faraway use sites look much better now. The performance sensitive usages need close attention. Can you summarise the changes to DatagramChannel, are you creating a NoOpScopeAcquisition for every  send/receive? This is low level code where we do do something different to avoid the try-with-resources.

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

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

From duke at openjdk.org  Tue Nov 22 09:38:12 2022
From: duke at openjdk.org (Ismael Juma)
Date: Tue, 22 Nov 2022 09:38:12 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
Message-ID: <vrCPeO8q_rSPwnS51968i5vGlFh4Z-xxQxkT9LWkYuQ=.55b3889b-80c5-4823-a2f8-1a7e9368ae2d@github.com>

On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework Acquisition

> because this PR is touching several low level and performance critical code paths

Indeed. Have we verified that performance doesn't regress with these changes?

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

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

From mcimadamore at openjdk.org  Tue Nov 22 09:38:15 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 22 Nov 2022 09:38:15 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
Message-ID: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>

On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework Acquisition

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914:

> 912:          * If so, make a copy to put the dst data in.
> 913:          */
> 914:         @SuppressWarnings("try")

After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with).

src/java.base/share/classes/java/nio/Buffer.java line 827:

> 825: 
> 826:                 @Override
> 827:                 public Runnable acquireSessionOrNull(Buffer buffer, boolean async) {

If allocation/performance is an issue, a relatively straightforward way to adjust the code would be to let go of the TWR entirely. E.g. we have code that does this:


Buffer b = ...
try {
    // use buffer.address();
} finally {
    Reference.reachabilityFence(b);
}


We could transform to this:


Buffer b = ...
acquire(b); // calls MemorySessionImpl.acquire0 if session is not null
try {
    // use buffer.address();
} finally {
    release(b); // calls MemorySessionImpl.release0 if session is not null (and maybe adds a reachability fence, just in case)
}

This leads to a simpler patch that is probably easier to validate. The remaining IOUtil code will be using a different idiom, and perhaps we can, at some point, go back and make that consistent too.

src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:

> 588:                                         int pos)
> 589:             throws IOException {
> 590:         try (var guard = NIO_ACCESS.acquireScope(bb)) {

Why was the old code not using reachability fences? Bug or feature?

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

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

From mcimadamore at openjdk.org  Tue Nov 22 09:42:23 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 22 Nov 2022 09:42:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
Message-ID: <RSewN9uSJ-RrZdoec7DHOLjEBlj29gRX4HIReXrnZBo=.b0ddb4a0-ad7c-4de6-9fc3-0d0e9cc418bc@github.com>

On Tue, 22 Nov 2022 09:32:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework Acquisition
>
> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:
> 
>> 588:                                         int pos)
>> 589:             throws IOException {
>> 590:         try (var guard = NIO_ACCESS.acquireScope(bb)) {
> 
> Why was the old code not using reachability fences? Bug or feature?

I see that there's a subsequent buffer call if `n > 0`, so that's probably why the fence was skipped? (I also assume that the code calling this method will access the buffer before/after, so reachability is never truly an issue - but for session-backed buffers this needs fixing).

Also, stepping back, I note how, if `receive0` was a native call using Linker, perhaps we wouldn't need all this manual address computation - we'd just get a memory segment slice from the buffer and pass that to the handle (which will perform the correct liveness check). E.g. maybe a better long term solution would be to panama-ize this code?

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

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

From duke at openjdk.org  Tue Nov 22 10:23:04 2022
From: duke at openjdk.org (ExE Boss)
Date: Tue, 22 Nov 2022 10:23:04 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
Message-ID: <UwTUKJq45-sC2tDcnUGqv1Uwv9cVn7etUEBK88WJhvw=.f30994f7-a292-43f7-a9c7-5d68abfead96@github.com>

On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework Acquisition

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 43:

> 41:     // try (var guard = NIO_ACCESS.acquireSession(bb)) {
> 42:     //     performOperation(bb.address());
> 43:     // }

Again, updating?this?comment was?missed:
Suggestion:

    // try (var guard = NIO_ACCESS.acquireScope(bb)) {
    //     performOperation(guard.address());
    // }

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

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

From alanb at openjdk.org  Tue Nov 22 12:00:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Nov 2022 12:00:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
Message-ID: <4GRnrg0zNGXoQdiG3uL9JeQyj4bdDVubzv0oMoIuSnM=.1dabdf13-e8b7-477d-86d0-20e5ba2f47bf@github.com>

On Tue, 22 Nov 2022 09:29:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework Acquisition
>
> src/java.base/share/classes/java/nio/Buffer.java line 827:
> 
>> 825: 
>> 826:                 @Override
>> 827:                 public Runnable acquireSessionOrNull(Buffer buffer, boolean async) {
> 
> If allocation/performance is an issue, a relatively straightforward way to adjust the code would be to let go of the TWR entirely. E.g. we have code that does this:
> 
> 
> Buffer b = ...
> try {
>     // use buffer.address();
> } finally {
>     Reference.reachabilityFence(b);
> }
> 
> 
> We could transform to this:
> 
> 
> Buffer b = ...
> acquire(b); // calls MemorySessionImpl.acquire0 if session is not null
> try {
>     // use buffer.address();
> } finally {
>     release(b); // calls MemorySessionImpl.release0 if session is not null (and maybe adds a reachability fence, just in case)
> }
> 
> This leads to a simpler patch that is probably easier to validate. The remaining IOUtil code will be using a different idiom, and perhaps we can, at some point, go back and make that consistent too.

The AutoCloseable experiment was interesting to try but I think you are right, acquire try { .. } finally release would be simpler and also remove the concerns about the performance critical code paths.

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

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

From alanb at openjdk.org  Tue Nov 22 12:00:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Nov 2022 12:00:24 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <RSewN9uSJ-RrZdoec7DHOLjEBlj29gRX4HIReXrnZBo=.b0ddb4a0-ad7c-4de6-9fc3-0d0e9cc418bc@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
 <RSewN9uSJ-RrZdoec7DHOLjEBlj29gRX4HIReXrnZBo=.b0ddb4a0-ad7c-4de6-9fc3-0d0e9cc418bc@github.com>
Message-ID: <WHS_9EM_JrRB2ZtSQmTO4qJLhOjPv5XCP0iGLbiqQ0k=.75963d9c-1c9b-4506-b234-74e8658e0d9a@github.com>

On Tue, 22 Nov 2022 09:38:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590:
>> 
>>> 588:                                         int pos)
>>> 589:             throws IOException {
>>> 590:         try (var guard = NIO_ACCESS.acquireScope(bb)) {
>> 
>> Why was the old code not using reachability fences? Bug or feature?
>
> I see that there's a subsequent buffer call if `n > 0`, so that's probably why the fence was skipped? (I also assume that the code calling this method will access the buffer before/after, so reachability is never truly an issue - but for session-backed buffers this needs fixing).
> 
> Also, stepping back, I note how, if `receive0` was a native call using Linker, perhaps we wouldn't need all this manual address computation - we'd just get a memory segment slice from the buffer and pass that to the handle (which will perform the correct liveness check). E.g. maybe a better long term solution would be to panama-ize this code?

Yes, once the memory/linker APIs are permanent then the SCTP implementation would be a good candidate to redo.

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

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

From pminborg at openjdk.org  Tue Nov 22 13:52:22 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 13:52:22 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
Message-ID: <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com>

On Tue, 22 Nov 2022 09:23:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework Acquisition
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914:
> 
>> 912:          * If so, make a copy to put the dst data in.
>> 913:          */
>> 914:         @SuppressWarnings("try")
> 
> After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with).

Well spotted. I will remove the guarding here.

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

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

From pminborg at openjdk.org  Tue Nov 22 14:01:39 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Nov 2022 14:01:39 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v10]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <VU9F8S77u_MTYUEeJNuEIVQzsDSvFjj5IrAp81VPJOw=.8408fba0-e45a-4551-9a41-9255e39640b1@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Remove redundant guard and fix comment permanently

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/0526e3dc..06c764ca

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

  Stats: 59 lines in 2 files changed: 19 ins; 26 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From mcimadamore at openjdk.org  Tue Nov 22 14:48:04 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 22 Nov 2022 14:48:04 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v29]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <bagsYNxX14Px2iI8CRdc2mo4M11QwmnnWJPljCH-gkI=.29852324-8631-4014-8f9f-2a35558ff0d3@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Fix wrong check in MemorySegment::spliterator/elements
  (The check which ensures that the segment size is multiple of spliterator element size is bogus)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/a0cee7b0..66dd888d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=27-28

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

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

From tsteele at openjdk.org  Tue Nov 22 17:46:27 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Tue, 22 Nov 2022 17:46:27 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
Message-ID: <N6C6XSpbxeWMpSX6JUmHJeL5w1CbwDgLKkO4FSnTQRQ=.4922a76e-0856-4067-989d-bc23bb17917f@github.com>

On Fri, 21 Oct 2022 21:43:25 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> This minor change fixes a compliance test failure which was partially addressed by https://github.com/openjdk/jdk/commit/1bb4de2e2868a539846ec48dd43fd623c2ba69a5. However the failure was still observed on select machines. This change addresses the remaining failures by ensuring that any new WatchKey is held until the polling thread becomes active.

The failing test is register_and_poll in JCK17. The JCK is copyrighted, so I'm not able to post about it publicly, but I believe you should have access to it.

Currently, PollingWatchService is used only on BSD/Macos and AIX. I don't believe the issue is platform specific. I think the issue that I describe below is extant on all platforms that use PollingWatchService, but some amount of platform specificity may make it more prominent on AIX.

> I think you mean "valid" rather than "active".

I meant active, but it's probably not clear what I meant by that. What I meant to say is that there is an 'activation window' in the code without this change. The window starts when [the call](https://github.com/openjdk/jdk/blob/0ac5b55311222d0531c9cfcec8c74932661b1750/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java#L317) to `scheduleAtFixedRate(POLLING_INIT_DELAY...)`, completes and ends when the first run of the [WatchKey `poll()`](https://github.com/openjdk/jdk/blob/0ac5b55311222d0531c9cfcec8c74932661b1750/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java#L342) method happens.

What the delay in this change is intended to do, is eliminate this 'activation window'. It does this by forcing register to wait for POLLING_INIT_DELAY to ensure the polling thread is running when it returns. My comment was meant to suggest, that a key should be "activ[ly]" polling for changes when it is returned by `register(...)`. POLLING_INIT_DELAY is an upper bound on the length of this 'activation window'.

I agree with your sentiment that adding a delay is not the most elegant solution. If you agree that changing POLLING_INIT_DELAY to 0 and removing the proposed delay is a good option, I am happy to run the test with that change to confirm that is a viable solution, and modify this PR.

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

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

From duke at openjdk.org  Tue Nov 22 19:28:27 2022
From: duke at openjdk.org (ExE Boss)
Date: Tue, 22 Nov 2022 19:28:27 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v9]
In-Reply-To: <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <ezZYMKTE2f_efcRusALcC8Bm5ahmX87rKicfjvDlgDc=.300b7304-7667-44f5-b755-d0c026a6de08@github.com>
 <leTW4o1u6OnfntozB2VE4SfZl2PuiCQ1XKEBfA-ubyg=.c1209d7b-9c34-4ecf-b2db-bbfdd51f35f3@github.com>
 <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com>
Message-ID: <-3UxCy1TSFrc9DMZZMdsiUpX7i3wOmiTRTHpyRKEjYs=.54eef999-bad4-49ce-9c66-d45fd16fe9b5@github.com>

On Tue, 22 Nov 2022 13:49:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914:
>> 
>>> 912:          * If so, make a copy to put the dst data in.
>>> 913:          */
>>> 914:         @SuppressWarnings("try")
>> 
>> After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with).
>
> Well spotted. I will remove the guarding here.

This?`@SuppressWarnings` annotation is?no?longer?needed:
Suggestion:

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

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

From alanb at openjdk.org  Tue Nov 22 19:32:19 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Nov 2022 19:32:19 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <N6C6XSpbxeWMpSX6JUmHJeL5w1CbwDgLKkO4FSnTQRQ=.4922a76e-0856-4067-989d-bc23bb17917f@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
 <N6C6XSpbxeWMpSX6JUmHJeL5w1CbwDgLKkO4FSnTQRQ=.4922a76e-0856-4067-989d-bc23bb17917f@github.com>
Message-ID: <JtoPU2zYSSyhgd8PfzdlhDOTaQD07TJzD3T0Q_usvtY=.8c02509d-b40e-446c-a270-7e51fd9e42c1@github.com>

On Tue, 22 Nov 2022 17:44:27 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> The failing test is register_and_poll in JCK17. The JCK is copyrighted, so I'm not able to post about it publicly, but I believe you should have access to it.
> 
> Currently, PollingWatchService is used only on BSD/Macos and AIX. I don't believe the issue is platform specific. I think the issue that I describe below is extant on all platforms that use PollingWatchService, but some amount of platform specificity may make it more prominent on AIX.

I think the issue is that the test registers a directory and immediately modifies a file in that directory. To an observer using the PollingWatchService, the file last modification time has not changed so the watch key is not queued. What is the precision of the time of last modification on AIX? On macOS there is nano precision timestamps so this might explain why the issue has not been observed there. In this case, this seems like something that the test needs to deal with.

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

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

From jjg at openjdk.org  Tue Nov 22 22:04:57 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 22 Nov 2022 22:04:57 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

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

  Prefix RFC titles with `RFC NNNN:`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/30ce235f..c29092d8

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

  Stats: 325 lines in 165 files changed: 4 ins; 4 del; 317 mod
  Patch: https://git.openjdk.org/jdk/pull/11073.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073

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

From mcimadamore at openjdk.org  Wed Nov 23 10:54:53 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 23 Nov 2022 10:54:53 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v30]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <kPdkyjB-7Po8sPr7weSbsWIIHf2TxnnQa9EBLfV3Wrc=.6b4612f8-03a7-47c4-8e25-36e4fe803e8f@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Fix bit vs. byte mismatch in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/66dd888d..3c75e097

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=28-29

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

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

From pminborg at openjdk.org  Wed Nov 23 12:21:07 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Nov 2022 12:21:07 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v11]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <Kjp4PS4MZ9xnK5J6RH0LkSqmiG4REMfF2HT62Ca67Mc=.f433fbb7-5a98-494f-a91e-6796d96e6edf@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Refactor to try-finally handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/06c764ca..88ae68b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=09-10

  Stats: 677 lines in 20 files changed: 286 ins; 152 del; 239 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From pminborg at openjdk.org  Wed Nov 23 12:39:40 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Nov 2022 12:39:40 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v12]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/88ae68b8..682b6f5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=10-11

  Stats: 23 lines in 9 files changed: 1 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From dfuchs at openjdk.org  Wed Nov 23 12:47:43 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 12:47:43 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
Message-ID: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>

On Tue, 22 Nov 2022 22:04:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefix RFC titles with `RFC NNNN:`

Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages?

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

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

From mcimadamore at openjdk.org  Wed Nov 23 16:17:40 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 23 Nov 2022 16:17:40 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v12]
In-Reply-To: <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>
Message-ID: <MQDSl6_Z03fIVTlGRbFN5Lmss4E36QPL_nR7k3Bfx6c=.7edeb46e-037a-46f9-ac5c-2cc58f91716e@github.com>

On Wed, 23 Nov 2022 12:39:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 125:

> 123:      * @see #releaseScope(Buffer, MemorySessionImpl)
> 124:      */
> 125:     MemorySessionImpl acquireScopeOrNull(Buffer buffer);

I think this looks better - but naming-wise it's still a bit problematic. This method really acquires the underlying session, not a scope. And also, here we have `OrNull`, but the already existing `acquireSession` also has a similar semantics w.r.t. null.

I suggest to rename:

* `acquireSession` -> `acquireSessionAsRunnable`
* `acquireScopeOrNull` -> `acquireSession`
* `releaseScope` -> `releaseSession`

Also, once we have `acquire/releaseSession`, it is not clear to me that we still need `acquireSessionAsRunnable` in the JavaNIOAccess class - it seems like you can create the Runnable where it's required (probably IOUtil), simply by using straight acquire/release.

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 164:

> 162:     int pageSize();
> 163: 
> 164:     sealed interface ScopeAcquisition extends AutoCloseable {

Is this still needed?

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

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

From jjg at openjdk.org  Wed Nov 23 16:47:22 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 16:47:22 GMT
Subject: RFR: 8296546: Add @spec tags to API [v2]
In-Reply-To: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <WQDNvUdT1_ZEaxIm2HMGUJFfMUjpaqklUVO_3uWypX8=.8900b742-92b5-4f53-a16b-1fb5e0e907fc@github.com>
 <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com>
Message-ID: <1chEBBDbhD7PiPdKybnhe3Bq2DyO-GTGaxTU5qtw7C4=.8191c086-d70c-4bc1-b03e-d781b1268f07@github.com>

On Wed, 23 Nov 2022 12:43:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages?

That was not intentional, and is a result of the scripted edit. I will look to revert those changes and/or change the tooling to ignore those packages.

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

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

From mcimadamore at openjdk.org  Wed Nov 23 17:33:06 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 23 Nov 2022 17:33:06 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v31]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <S9AFA1STby7c240-cSlvO-e0MekMt-uKHFAqUbOnoOU=.fdab60c5-eeb5-4f5e-b189-409225b7500f@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  * remove unused Scoped interface
  * re-add trusting of final fields in layout class implementations
  * Fix BulkOps benchmark, which had alignment issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/3c75e097..97168155

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=29-30

  Stats: 56 lines in 5 files changed: 8 ins; 39 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

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

From pminborg at openjdk.org  Wed Nov 23 17:40:24 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Nov 2022 17:40:24 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v12]
In-Reply-To: <MQDSl6_Z03fIVTlGRbFN5Lmss4E36QPL_nR7k3Bfx6c=.7edeb46e-037a-46f9-ac5c-2cc58f91716e@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <D61AgLIs44FlEwLIr_otiba5kOwmDbyCCZJaMhJJzwQ=.969e6215-395d-4949-8f9d-4919507ab89a@github.com>
 <MQDSl6_Z03fIVTlGRbFN5Lmss4E36QPL_nR7k3Bfx6c=.7edeb46e-037a-46f9-ac5c-2cc58f91716e@github.com>
Message-ID: <R-M2NOUc9X1tA-Pe-Jm81A06WpAJ-NizI8IliAGDMR4=.e8c0957c-f78b-4573-8e68-90e90df6c101@github.com>

On Wed, 23 Nov 2022 16:14:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup
>
> src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 125:
> 
>> 123:      * @see #releaseScope(Buffer, MemorySessionImpl)
>> 124:      */
>> 125:     MemorySessionImpl acquireScopeOrNull(Buffer buffer);
> 
> I think this looks better - but naming-wise it's still a bit problematic. This method really acquires the underlying session, not a scope. And also, here we have `OrNull`, but the already existing `acquireSession` also has a similar semantics w.r.t. null.
> 
> I suggest to rename:
> 
> * `acquireSession` -> `acquireSessionAsRunnable`
> * `acquireScopeOrNull` -> `acquireSession`
> * `releaseScope` -> `releaseSession`
> 
> Also, once we have `acquire/releaseSession`, it is not clear to me that we still need `acquireSessionAsRunnable` in the JavaNIOAccess class - it seems like you can create the Runnable where it's required (probably IOUtil), simply by using straight acquire/release.

The name "scope" was used in anticipation of the new proposed Java 20 naming. But I can change it back to session again. We could always rename later.

> src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 164:
> 
>> 162:     int pageSize();
>> 163: 
>> 164:     sealed interface ScopeAcquisition extends AutoCloseable {
> 
> Is this still needed?

Well spotted.

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

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

From jjg at openjdk.org  Wed Nov 23 18:57:03 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 18:57:03 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

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

  Remove updates from unexported files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/c29092d8..3905ac83

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

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

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

From tsteele at openjdk.org  Wed Nov 23 19:13:23 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Wed, 23 Nov 2022 19:13:23 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <JtoPU2zYSSyhgd8PfzdlhDOTaQD07TJzD3T0Q_usvtY=.8c02509d-b40e-446c-a270-7e51fd9e42c1@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
 <N6C6XSpbxeWMpSX6JUmHJeL5w1CbwDgLKkO4FSnTQRQ=.4922a76e-0856-4067-989d-bc23bb17917f@github.com>
 <JtoPU2zYSSyhgd8PfzdlhDOTaQD07TJzD3T0Q_usvtY=.8c02509d-b40e-446c-a270-7e51fd9e42c1@github.com>
Message-ID: <zcEE4RIpxUHOmo-DgI3JBe2YSmItGsxGplBvFq6d13s=.a612940e-362c-45de-bcff-3d4b37252461@github.com>

On Tue, 22 Nov 2022 19:28:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think the issue is that the test registers a directory and immediately modifies a file in that directory. To an observer using the PollingWatchService, the file last modification time has not changed so the watch key is not queued... What is the precision of the time of last modification on AIX?

A reasonable explanation, but I disagree with the conclusion. The implementation of getLastModifiedTime comes from UnixFileSystem code which is similar between the Unixes [2]. To your question, AIX uses nanosecond information to compute the mtime as well. In addition, PollingWatchService explicitly converts the modification time to milliseconds [1].

> In passing, I would like to see POLLING_INIT_DELAY (added by JDK-8285956) be removed as it's inconsistent to start polling after 1s when the polling rate is 2s. The original code was correct.

Does this mean that you'd prefer the polling rate match always match the initial delay? I can see an argument for this. But in that case, I would advocate for the addition of a delay like the one proposed by this PR. Once the call to register a path returns, I think it's reasonable to assume that any change to the registered Watchable would be noticed by the WatchService. If the activation window that I describe is present, any changes made during that time can not be noticed because the polling thread is not running yet [3].

---

It may be worth clarifying that my changes were not intended just to make the test pass. It's  my belief that there is a real issue with the presence of this activation window, which PollingWatchService would benefit from removing. I am happy to discuss the best method for doing so.


Result of changing InitDelay and Interval. Changes are not reported until p_0.
scheduleAtFixedRate(thunk, InitDelay, Interval TimeUnit.SECONDS);

# Current
| InitDelay | Interval | ... | Interval |
           p_0        p_1   p_n       p_n+1
|<--------->| activation window

# Pre-8285956
| Interval | Interval | ... | Interval |
          p_0        p_1   p_n       p_n+1
|<-------->| activation window

# Proposed Change
| InitDelay | ... | Interval |
p_0        p_1   p_n       p_n+1

Legend:
InitDelay: is the POLLING_INIT_DELAY
Interval: is the DEFAULT_POLLING_INTERVAL
p_0: is the first poll run by the polling thread
p_n: is the (n+1)th poll by the polling thread


[1] https://github.com/openjdk/jdk/blob/2afb4c3327b6830a009ee1ab8a1eb7803ef53007/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java#L367
[2] https://github.com/openjdk/jdk/blob/2afb4c3327b6830a009ee1ab8a1eb7803ef53007/src/java.base/unix/native/libjava/UnixFileSystem_md.c#L226-L247
[3] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/ScheduledExecutorService.html#scheduleAtFixedRate(java.lang.Runnable,long,long,java.util.concurrent.TimeUnit)

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

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

From dfuchs at openjdk.org  Wed Nov 23 19:23:53 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Nov 2022 19:23:53 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though.

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

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

From jjg at openjdk.org  Wed Nov 23 22:09:23 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 23 Nov 2022 22:09:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <WospQd-HxT32GBhC5u-27e5zl1wamzqwrTPB0HkcN3o=.02c7c859-d66c-413c-a730-71bf6e5b7979@github.com>
Message-ID: <CN_yhlxSOuJ_vrZwgtwLXWapiBa9Df2Cab1ySShZvu4=.b3e2212d-2f5d-4cea-a28b-8a02e3b18159@github.com>

On Wed, 23 Nov 2022 19:20:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though.

Believe me, I tried *very* hard to design and use an inline `{@spec}` tag but such a tag effectively needs a normative external file to indicate the root of a multi-page spec, and the definitive title, since inline tags either do not or are unlikely to contain such information.

The general history of this work is:
* version 1: bimodal tag with no external file -- the content of the summary page was effectively rubbish
* version 2: bimodal tag with an external file -- in discussion with @jddarcy and CSR, we decided that was too much of a non-standard maintenance load
* version 3: new tag, with no external file needed -- as you see here

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

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

From joehw at openjdk.org  Wed Nov 23 23:08:05 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 23 Nov 2022 23:08:05 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.xml/share/classes/javax/xml/XMLConstants.java line 35:

> 33:  * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition)
> 34:  * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition)
> 35:  * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition

Hi Jon,

I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0.
points to the fifth edition while @see second.

A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read.

[1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html

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

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

From joehw at openjdk.org  Wed Nov 23 23:43:57 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 23 Nov 2022 23:43:57 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <3O_lqMPzsBuGyrQ_snbw0Qv-XY-OaGUly6OBtoRz8hw=.041bf0b3-9dd4-4616-a003-617d28030139@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

Specs for XSLT and XPath (many occurrences) need to point to specific version (e.g. 1.0) rather than the "cover page" (this is an issue in the original javadoc).

src/java.xml/share/classes/javax/xml/transform/OutputKeys.java line 35:

> 33:  *
> 34:  * @spec https://www.w3.org/TR/xslt xslt cover page - W3C
> 35:  * @see <a href="http://www.w3.org/TR/xslt#output">

The pages for XSLT and XPath at W3C are organized differently from the days when this javadoc was created. The "latest version" now points to the "cover page". Could you change the spec to the following? 
      https://www.w3.org/TR/1999/REC-xslt-19991116 XSL Transformations (XSLT) Version 1.0
      
The @spec points to the general spec while @see also a specific section (similar situation as other classes in the package), if we want to keep @see ref here, it would be: 
    https://www.w3.org/TR/1999/REC-xslt-19991116#output

src/java.xml/share/classes/javax/xml/xpath/XPath.java line 104:

> 102:  * @author  Norman Walsh
> 103:  * @author  Jeff Suttor
> 104:  * @see <a href="http://www.w3.org/TR/xpath">XML Path Language (XPath) Version 1.0</a>

Similar situation as XSLT above, the latest version now points to "cover page". For this javadoc then, it needs to be:
    https://www.w3.org/TR/1999/REC-xpath-19991116/ XML Path Language (XPath) Version 1.0
    
Unlike XSLT, the original @see ref also points to the spec generally (not a specific section), we could then drop it to keep just the @spec ref.

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

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

From alanb at openjdk.org  Thu Nov 24 09:02:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Nov 2022 09:02:18 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <zcEE4RIpxUHOmo-DgI3JBe2YSmItGsxGplBvFq6d13s=.a612940e-362c-45de-bcff-3d4b37252461@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
 <N6C6XSpbxeWMpSX6JUmHJeL5w1CbwDgLKkO4FSnTQRQ=.4922a76e-0856-4067-989d-bc23bb17917f@github.com>
 <JtoPU2zYSSyhgd8PfzdlhDOTaQD07TJzD3T0Q_usvtY=.8c02509d-b40e-446c-a270-7e51fd9e42c1@github.com>
 <zcEE4RIpxUHOmo-DgI3JBe2YSmItGsxGplBvFq6d13s=.a612940e-362c-45de-bcff-3d4b37252461@github.com>
Message-ID: <-tPn-83pafiAnATErF8OLTLR7BetQ77vdamo4UOofXQ=.69337422-e19c-45bb-bd0a-60fff93094de@github.com>

On Wed, 23 Nov 2022 19:11:06 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> A reasonable explanation, but I disagree with the conclusion. The implementation of getLastModifiedTime comes from UnixFileSystem code which is similar between the Unixes [2]. To your question, AIX uses nanosecond information to compute the mtime as well. In addition, PollingWatchService explicitly converts the modification time to milliseconds [1].

Would it be possible to run this on the AIX system and paste in the output? The output is just the last modified time, it wouldn't reveal anything about the system.

            Path file = Files.createTempFile("foo", "bin");
            try {
                FileTime t0 = Files.getLastModifiedTime(file);
                try (var ch = Files.newByteChannel(file, StandardOpenOption.APPEND)) {
                    ch.write(ByteBuffer.allocate(1000));
                }
                FileTime t1 = Files.getLastModifiedTime(file);
                System.out.format("%s%n%s%n", t0, t1);
            } finally {
                Files.delete(file);
            }

I think this is close to the test that is failing for you. The main thing I'd like to see is whether the time of last modification is changed or not.
 
> Does this mean that you'd prefer the polling rate match always match the initial delay? I can see an argument for this. But in that case, I would advocate for the addition of a delay like the one proposed by this PR. Once the call to register a path returns, I think it's reasonable to assume that any change to the registered Watchable would be noticed by the WatchService.

Registering a directory to watch will first scan the directory to get the names and time of last modification for all entries. This is done by the register method before before it adds the directory to the map that is scanned by the poller thread. Hopefully this makes it clearer why POLLING_INIT_DELAY doesn't really make sense. It means first the poller thread will do its first poll of all directories from 1s of first registration, then at 2s interacts thereafter.

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

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

From alanb at openjdk.org  Thu Nov 24 09:17:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Nov 2022 09:17:18 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <-tPn-83pafiAnATErF8OLTLR7BetQ77vdamo4UOofXQ=.69337422-e19c-45bb-bd0a-60fff93094de@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
 <N6C6XSpbxeWMpSX6JUmHJeL5w1CbwDgLKkO4FSnTQRQ=.4922a76e-0856-4067-989d-bc23bb17917f@github.com>
 <JtoPU2zYSSyhgd8PfzdlhDOTaQD07TJzD3T0Q_usvtY=.8c02509d-b40e-446c-a270-7e51fd9e42c1@github.com>
 <zcEE4RIpxUHOmo-DgI3JBe2YSmItGsxGplBvFq6d13s=.a612940e-362c-45de-bcff-3d4b37252461@github.com>
 <-tPn-83pafiAnATErF8OLTLR7BetQ77vdamo4UOofXQ=.69337422-e19c-45bb-bd0a-60fff93094de@github.com>
Message-ID: <6XJYNOoCdsjYeQZ-xp1VO0D4sLPtHkhDGbelDoy3IZs=.8077bf9d-5d9c-4b11-9526-075653e7f554@github.com>

On Thu, 24 Nov 2022 08:59:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The implementation of getLastModifiedTime comes from UnixFileSystem code which is similar between the Unixes [2]. 

The implementation used is libnio/fs/UnixNativeDispatcher.c and there may be porting work required there to get timestamps with a precision of more than 1s. That is, it looks like AIX may use st_mtime_n rather than st_mtimespec.tv_nsec.

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

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

From alanb at openjdk.org  Thu Nov 24 10:56:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Nov 2022 10:56:23 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <W_PDXjCTWZO6xXPHhF-LLKnDxtRgwgI9zdv9Se52Rqo=.0ae98a38-5f76-4839-b579-ab19faf1945b@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.se/share/classes/module-info.java line 39:

> 37:  *
> 38:  * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol
> 39:  * @spec jni/index.html Java Native Interface Specification

One thing that that bothers me a bit here is that the JNI and JDWP specs will be listed as "External Specifications" in the generated javadoc. This heading is appropriate for RFCs and other standards that we reference but seems misleading for specifications that are part of Java SE. Has this come up already?

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

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

From pminborg at openjdk.org  Thu Nov 24 11:42:52 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 11:42:52 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Remove redundant method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/682b6f5a..0546b23b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=11-12

  Stats: 213 lines in 20 files changed: 12 ins; 105 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From mcimadamore at openjdk.org  Thu Nov 24 11:53:28 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 11:53:28 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
Message-ID: <U9NPKtU24wSF4q7X1EkgR2dbIW5k3Oe1mLs8iqAs1Ks=.c12f9a79-db57-46d0-8ccd-b26c0a077816@github.com>

On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant method

Looks good - I'm glad that the changes to IOUtil turned out simpler than expected!

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

Marked as reviewed by mcimadamore (Reviewer).

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

From mcimadamore at openjdk.org  Thu Nov 24 11:57:09 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 11:57:09 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
Message-ID: <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>

On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant method

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519:

> 517:     }
> 518: 
> 519:     record LinkedRunnable(Runnable node, Runnable next)

Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes.

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

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

From mcimadamore at openjdk.org  Thu Nov 24 12:00:21 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 12:00:21 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
Message-ID: <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>

On Thu, 24 Nov 2022 11:54:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant method
>
> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519:
> 
>> 517:     }
>> 518: 
>> 519:     record LinkedRunnable(Runnable node, Runnable next)
> 
> Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes.

Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line).

Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd.

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

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

From mcimadamore at openjdk.org  Thu Nov 24 12:00:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Nov 2022 12:00:22 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
 <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>
Message-ID: <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com>

On Thu, 24 Nov 2022 11:57:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519:
>> 
>>> 517:     }
>>> 518: 
>>> 519:     record LinkedRunnable(Runnable node, Runnable next)
>> 
>> Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes.
>
> Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line).
> 
> Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd.

(to be clear, some of the above comments refer to the code that was already there before your changes)

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

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

From alanb at openjdk.org  Thu Nov 24 12:17:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Nov 2022 12:17:06 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
Message-ID: <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>

On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant method

src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 790:

> 788:         try {
> 789:             int n = receive0(fd,
> 790:                     ((DirectBuffer)bb).address() + pos, rem,

Would it be possible to restore the original alignment, just to make it easier to read.

src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 39:

> 37:     // silent unrelated memory mutation and JVM crashes.
> 38:     //
> 39:     // Guards are available in the JavaNioAccess class.

Did you mean to leave the word "Guards" in the comment? I guess I would say something "See JavaNioAccess for methods to acquire/release" or something like that.

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480:

> 478:     static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) {
> 479:         if (async && NIO_ACCESS.isThreadConfined(bb)) {
> 480:             throw new IllegalStateException("Confined session not supported");

No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify.

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 543:

> 541:         @Override public void run() { releaseScope(bb, session); }
> 542:         static Runnable of(ByteBuffer bb, MemorySessionImpl session) { return new Releaser(bb, session); }
> 543:         static Runnable ofNullable(ByteBuffer bb, MemorySessionImpl session) {

Would it be possible to re-format this to make it more readable? There's just a bit more going on compared to the original and it's harder to read.

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

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

From pminborg at openjdk.org  Thu Nov 24 14:52:15 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 14:52:15 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com>
 <gU2xKdFB7OQ9h0iFWfEtmT8KEvJOb4xWA5NnaSMTQek=.88496188-3131-4694-acce-693b133db209@github.com>
 <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com>
Message-ID: <dy4zEuWXA_iymssRu8PCeqXXnU77AA-ncC3veSg6xOA=.7d822c4a-9c34-4e1b-9dcf-6d6956601e4b@github.com>

On Thu, 24 Nov 2022 11:58:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line).
>> 
>> Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd.
>
> (to be clear, some of the above comments refer to the code that was already there before your changes)

I also found the above as a bit odd but tried to stick with the existing implementation and style as much as possible.

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

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

From pminborg at openjdk.org  Thu Nov 24 14:58:19 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 14:58:19 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
Message-ID: <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>

On Thu, 24 Nov 2022 12:06:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant method
>
> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480:
> 
>> 478:     static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) {
>> 479:         if (async && NIO_ACCESS.isThreadConfined(bb)) {
>> 480:             throw new IllegalStateException("Confined session not supported");
> 
> No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify.

This was the old behaviour which was retained in this PR.

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

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

From pminborg at openjdk.org  Thu Nov 24 16:21:42 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Nov 2022 16:21:42 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Reformat and fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/0546b23b..30aff118

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=12-13

  Stats: 26 lines in 3 files changed: 13 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From duke at openjdk.org  Fri Nov 25 06:49:27 2022
From: duke at openjdk.org (ExE Boss)
Date: Fri, 25 Nov 2022 06:49:27 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
 <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>
Message-ID: <qrdVZaVYz2VIcYJTH7S7GUSwTrH-ZghiljZBwIGGIxo=.4b0f5caf-b7dc-4f23-b87a-a0e9efa5cdfa@github.com>

On Thu, 24 Nov 2022 14:56:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480:
>> 
>>> 478:     static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) {
>>> 479:         if (async && NIO_ACCESS.isThreadConfined(bb)) {
>>> 480:             throw new IllegalStateException("Confined session not supported");
>> 
>> No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify.
>
> This was the old behaviour which was retained in this PR.

I?believe `UnsupportedOperationException` would?be?better for?this.

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

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

From alanb at openjdk.org  Fri Nov 25 07:17:08 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Nov 2022 07:17:08 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v13]
In-Reply-To: <qrdVZaVYz2VIcYJTH7S7GUSwTrH-ZghiljZBwIGGIxo=.4b0f5caf-b7dc-4f23-b87a-a0e9efa5cdfa@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <BSTGswebYJRK1K3czXRfUbQs-gBWC7ZUBnsKQ-HrMME=.ad304498-3513-4f1f-8778-7fe5906b541b@github.com>
 <KvRlHjVUaGzuSXkvEwoAR5iY9XP7pWloKAXy3kZeUqE=.4de4b313-3efa-43b8-85b5-660cf1a63b56@github.com>
 <RlDmvAQMKwNcHTPn0aFzIN65xrBg8T2yeXNbcMZWcEU=.69206d97-8789-4110-ad93-3b5b6c79f31d@github.com>
 <qrdVZaVYz2VIcYJTH7S7GUSwTrH-ZghiljZBwIGGIxo=.4b0f5caf-b7dc-4f23-b87a-a0e9efa5cdfa@github.com>
Message-ID: <AaszrcsHg-zt8e_GlzGdKqfyrJ-mbkKIgVmUDxjzJWc=.cfca580b-34e7-458b-b3d1-daedc73e1ba9@github.com>

On Fri, 25 Nov 2022 06:46:52 GMT, ExE Boss <duke at openjdk.org> wrote:

> I?believe `UnsupportedOperationException` would?be?better for?this.

It would but Per is right that this it is throwing ISE today, it's just that the PR adds an explicit check and that highlights that the wrong exception is thrown. Buffers that are views over memory that is thread confined can't be used with the AsynchronousXXXX APIs and this will needed to be specified. There is further work required in this area too because IOUtil was intended for synchronous I/O. The "async" support was added on a temporary basis and will need to be re-visited at some point.

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

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

From aturbanov at openjdk.org  Sun Nov 27 13:19:42 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 27 Nov 2022 13:19:42 GMT
Subject: RFR: 8297682: Use Collections.emptyIterator where applicable
Message-ID: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>

Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method.
Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method.

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

Commit messages:
 - [PATCH] Use Collections.emptyIterator where applicable

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

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

From stsypanov at openjdk.org  Sun Nov 27 13:19:42 2022
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 27 Nov 2022 13:19:42 GMT
Subject: RFR: 8297682: Use Collections.emptyIterator where applicable
In-Reply-To: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
References: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
Message-ID: <6rFqYLhDhYjxOfHSG050VYx2UXZT9Abc6yktHUS1Q8o=.9445de4e-aadd-4b8a-93b8-195e0f8efb89@github.com>

On Mon, 7 Nov 2022 17:30:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method.
> Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method.

LGTM

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

Marked as reviewed by stsypanov (Author).

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

From alanb at openjdk.org  Sun Nov 27 15:34:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 27 Nov 2022 15:34:55 GMT
Subject: RFR: 8297682: Use Collections.emptyIterator where applicable
In-Reply-To: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
References: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
Message-ID: <DnrMBX7jSE0YBN1SRWgMjbWSKGBgU8fqlpsdyNb36DI=.8e27e4d0-186f-4d5f-b646-5ab273aae853@github.com>

On Mon, 7 Nov 2022 17:30:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method.
> Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method.

The change to UnixFileSystem::getRootDirectories looks okay.

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

Marked as reviewed by alanb (Reviewer).

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

From alanb at openjdk.org  Sun Nov 27 16:59:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 27 Nov 2022 16:59:51 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
Message-ID: <Z2mQfsenB-2TKri8E4p_2REW20k6KEl4yy4TQnGBVvA=.e8d51dc4-afcf-4ef5-9e5a-d575db38bb49@github.com>

On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat and fix comment

The latest version (30aff118) looks quite good but the naming at the use sites (`var scope = NIO_ACCESS.acquireSession(buffer);`) is temporarily confusing. Will that be fixed with the JEP  434 integrated or soon afterwards?

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

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

From alanb at openjdk.org  Sun Nov 27 17:09:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 27 Nov 2022 17:09:20 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
Message-ID: <Pc74reEYC1KV1FK_32D_pMa_9tlnJhMaBtZbLupg59w=.c7c124e1-01e1-4579-942b-f7698aee0eb6@github.com>

On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat and fix comment

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

> 592:                     try {
> 593:                         result = deflateBufferBytes(zsRef.address(),
> 594:                                 ((DirectBuffer) input).address() + inputPos, inputRem,

Somewhat subjective but the original code, with inputAddress, was a easier to read and avoided having too much going on in the parameters to deflateBufferBytes. In any case, you probably should fix the formatting to avoid have different parameters with different indentations.

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

> 715:                         result = deflateBytesBuffer(zsRef.address(),
> 716:                             inputArray, inputPos, inputLim - inputPos,
> 717:                                 ((DirectBuffer) output).address() + outputPos, outputRem,

Same here, I think I would keep outputAddress to keep the call to deflateByteBuffer simple.

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

> 738:                             try {
> 739:                                 result = deflateBufferBuffer(zsRef.address(),
> 740:                                     ((DirectBuffer) input).address() + inputPos, inputRem,

Another one where inputAddress and outputAddress have been removed so the call to deflatBufferBuffer is much hard to digest.

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

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

From mernst at openjdk.org  Sun Nov 27 17:53:30 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Sun, 27 Nov 2022 17:53:30 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.

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

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

From pminborg at openjdk.org  Mon Nov 28 08:38:55 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Nov 2022 08:38:55 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v14]
In-Reply-To: <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <JKwAdAZ_bckmzrWs_gFytpZlGXt3yaKX_cx5djdFjjc=.5b21945c-fe4d-4c25-9a12-ffa452aa0a19@github.com>
Message-ID: <lbi3L0o3TxVCaymOyYjKQ5BgYf3qrYkgwaYn0FcDX3Q=.1120c1d3-0375-48bd-af6f-4d6495ff6d86@github.com>

On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat and fix comment

> The latest version ([30aff11](https://github.com/openjdk/jdk/commit/30aff1187d4978c59d1e6feebafc2d45aba3e5f2)) looks quite good but the naming at the use sites (`var scope = NIO_ACCESS.acquireSession(buffer);`) is temporarily confusing. Will that be fixed with the JEP 434 integrated or soon afterwards?

The name was selected in anticipation of the proposed renaming in JEP 434. I think once the JEP is merged, we can rename some of the methods (*Session* -> *Scope*) and then the user site naming would be much better. Another alternative, which certainly can be done, is to rename `scope` to `session` and then rename these back again when the JEP is merged. What is the preferred way in your opinion?

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

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

From jpai at openjdk.org  Mon Nov 28 09:02:13 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 09:02:13 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
Message-ID: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>

On Sun, 27 Nov 2022 17:49:57 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.

I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

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

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

From jpai at openjdk.org  Mon Nov 28 09:07:24 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 09:07:24 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk,
 test/jdk/jni
Message-ID: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>

Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.

I'll raise separate PRs in the other remaining areas from that other PR.

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

Commit messages:
 - 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

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

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

From alanb at openjdk.org  Mon Nov 28 09:13:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 09:13:34 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <wvex0wjU2GnSsQ0xKXEHiZTVjMSeNGcGIG0BOHUJJtw=.93cd0d8d-cbea-4948-b439-d9049ad6e2e2@github.com>

On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.org  Mon Nov 28 09:56:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 09:56:14 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <p2HJTGMmmtudhqHdU-BrKrAZyn57gU3-4i5VU_9ZeLU=.a156a351-c15c-4480-a0ff-ef7a0699b9ba@github.com>

On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/WithHelperPublisher.java line 67:

> 65:    * to generate elements type your Subscriber is able to consume.
> 66:    * <p>
> 67:    * Sometimes you may want to implement your own custom helper Publisher - to validate behaviour of a Subscriber

The comment on the original PR is that this is a 3rd party code and not clear if it should be changed.

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

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

From jpai at openjdk.org  Mon Nov 28 10:02:47 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 10:02:47 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

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

  Address review comment - don't change WithHelperPublisher.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11385/files
  - new: https://git.openjdk.org/jdk/pull/11385/files/85669caf..37a51582

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

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

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

From jpai at openjdk.org  Mon Nov 28 10:02:50 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Nov 2022 10:02:50 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <p2HJTGMmmtudhqHdU-BrKrAZyn57gU3-4i5VU_9ZeLU=.a156a351-c15c-4480-a0ff-ef7a0699b9ba@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <p2HJTGMmmtudhqHdU-BrKrAZyn57gU3-4i5VU_9ZeLU=.a156a351-c15c-4480-a0ff-ef7a0699b9ba@github.com>
Message-ID: <GjK3gjMVUR8FxMELtrWBgSirJ-SDQR1mxc-UbzQ6GNs=.5bf874ca-47e8-4609-acab-bceae129bb49@github.com>

On Mon, 28 Nov 2022 09:54:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comment - don't change WithHelperPublisher.java
>
> test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/WithHelperPublisher.java line 67:
> 
>> 65:    * to generate elements type your Subscriber is able to consume.
>> 66:    * <p>
>> 67:    * Sometimes you may want to implement your own custom helper Publisher - to validate behaviour of a Subscriber
> 
> The comment on the original PR is that this is a 3rd party code and not clear if it should be changed.

Hello Alan, I have now updated this PR to remove changes to this file.

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

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

From pminborg at openjdk.org  Mon Nov 28 10:36:40 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Nov 2022 10:36:40 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v15]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <efCI-WqPRK4YGiXgedqunlh7KT0358jFuvt2FiWa5kU=.37256f78-e2ce-4c09-a356-c4907db2d490@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Re-introduce address variables

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/30aff118..95c40581

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=13-14

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

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

From alanb at openjdk.org  Mon Nov 28 10:40:11 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 10:40:11 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v15]
In-Reply-To: <efCI-WqPRK4YGiXgedqunlh7KT0358jFuvt2FiWa5kU=.37256f78-e2ce-4c09-a356-c4907db2d490@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <efCI-WqPRK4YGiXgedqunlh7KT0358jFuvt2FiWa5kU=.37256f78-e2ce-4c09-a356-c4907db2d490@github.com>
Message-ID: <PhLwZqHpoyEWcne_UFcklZ4_Jz-gMRjYM4DId_9_YJ8=.602fe5db-c3d0-4513-843d-1c51c5574ac7@github.com>

On Mon, 28 Nov 2022 10:36:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-introduce address variables

> The name was selected in anticipation of the proposed renaming in JEP 434. I think once the JEP is merged, we can rename some of the methods (_Session_ -> _Scope_) and then the user site naming would be much better. Another alternative, which certainly can be done, is to rename `scope` to `session` and then rename these back again when the JEP is merged. What is the preferred way in your opinion?

Whatever is easiest. Given the fork for JDK 20 is coming up soon then it would be good to get the rename done soon after JEP 434 integrates, just to avoid JDK 20 having the mix of names.

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

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

From pminborg at openjdk.org  Mon Nov 28 10:47:47 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Nov 2022 10:47:47 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Re-introduce yet another address vairable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/95c40581..eedf41ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=14-15

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

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

From lancea at openjdk.org  Mon Nov 28 11:29:09 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 28 Nov 2022 11:29:09 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
Message-ID: <Llh9tEhkVodoFQQR2a5Y3RS11724tea047BLBNjKXBo=.9c80845e-9d21-47bf-afce-49ed2e43c855@github.com>

On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
>> 
>> I'll raise separate PRs in the other remaining areas from that other PR.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment - don't change WithHelperPublisher.java

Marked as reviewed by lancea (Reviewer).

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

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

From jvernee at openjdk.org  Mon Nov 28 12:11:00 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Nov 2022 12:11:00 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v31]
In-Reply-To: <S9AFA1STby7c240-cSlvO-e0MekMt-uKHFAqUbOnoOU=.fdab60c5-eeb5-4f5e-b189-409225b7500f@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <S9AFA1STby7c240-cSlvO-e0MekMt-uKHFAqUbOnoOU=.fdab60c5-eeb5-4f5e-b189-409225b7500f@github.com>
Message-ID: <y4Faezp2kScZfX03dUS2tr_xXBDBIBoRiAOdrjIbIFs=.0c07c6e6-4d60-4e20-93cd-20c5cfdee93d@github.com>

On Wed, 23 Nov 2022 17:33:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove unused Scoped interface
>   * re-add trusting of final fields in layout class implementations
>   * Fix BulkOps benchmark, which had alignment issues

Latest version looks good to me as well

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

Marked as reviewed by jvernee (Reviewer).

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

From alanb at openjdk.org  Mon Nov 28 14:12:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Nov 2022 14:12:55 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
Message-ID: <8-MFynuwsRGfpV5mqTvonYTwphy5h1Jzs0CO31Og-wQ=.1ec9c4d4-d7dd-4dd6-96de-d6aa60d89930@github.com>

On Mon, 28 Nov 2022 10:47:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable.
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-introduce yet another address vairable

Thanks for persisting with it, latest version looks okay to me and the naming issue can be sorted out after the JEP is integrated.

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

Marked as reviewed by alanb (Reviewer).

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

From dfuchs at openjdk.org  Mon Nov 28 14:27:32 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Nov 2022 14:27:32 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
Message-ID: <6IgwmfUT8rOETK23hGf9t27oV1vdSLUUNr7QOvsmjII=.aa65f8e7-8c7a-4d3f-aa69-ef899725bcb4@github.com>

On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
>> 
>> I'll raise separate PRs in the other remaining areas from that other PR.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment - don't change WithHelperPublisher.java

Marked as reviewed by dfuchs (Reviewer).

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

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

From mcimadamore at openjdk.org  Mon Nov 28 15:00:32 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Nov 2022 15:00:32 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <vX9B3xTKhzAl3uVrWSkyiyH9NkMjzG4ry3gcCLdvTzo=.20b0b3b4-8020-4844-a05c-358090533806@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <eS00ZGo8A_JFM0e3JNPM8X5hHK9IFqa5MeZ9jX9kDJ8=.2e37c0fa-86b2-49ea-ab58-78ee0ab8432b@github.com>
 <cnAy75ur2HnzPT_w2zUsmnGTjWBqRSlKspMcR7K2684=.3ca69f20-0141-4cdd-8033-15e98aac0600@github.com>
 <vX9B3xTKhzAl3uVrWSkyiyH9NkMjzG4ry3gcCLdvTzo=.20b0b3b4-8020-4844-a05c-358090533806@github.com>
Message-ID: <DPv9DAmeB5tuC5ax2uEHDxtJbGvuNsn_9ZywyI6Q9Cg=.f8b48d3b-4c1b-4d0d-b5e6-e4240e67c5c8@github.com>

On Mon, 21 Nov 2022 12:05:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them.
>
> I'd prefer to see this comment removed from all places that are obviously interacting with the direct buffer cache. These usages are try-finally to acquire and return the temporary direct buffer cache back to the cache. Talking about closable sessions here is definitely confusing.

> Thanks for persisting with it, latest version looks okay to me and the naming issue can be sorted out after the JEP is integrated.


IMHO the renaming is not super important - the underlying abstraction managing the segment lifetime is still called MemorySession, even after https://git.openjdk.org/jdk/pull/10872. And, acquire/release are methods on MemorySession - so I think the current name might be more precise even after we integrate the latest API changes.

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

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

From prappo at openjdk.org  Mon Nov 28 15:04:12 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 28 Nov 2022 15:04:12 GMT
Subject: RFR: 8297682: Use Collections.emptyIterator where applicable
In-Reply-To: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
References: <o7RAAnRzCwSr2hZNLfR810vGFELDPIQCdJACQ1wqFx8=.6a9a7a60-a6b9-484f-b453-9052b275f3e8@github.com>
Message-ID: <c9hwrb-rLzgptbzcWoMtWj_ql0SndkSSSpepBOvqcGg=.1968e2b7-5953-4e28-b230-0bc538bd4b80@github.com>

On Mon, 7 Nov 2022 17:30:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method.
> Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method.

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 192:

> 190:                     return allowedList.iterator();
> 191:                 } catch (SecurityException x) {
> 192:                     return Collections.emptyIterator(); //disallowed

Alternatively, you could use the exception parameter to capture that comment:

    } catch (SecurityException disallowed) {

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

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

From pminborg at openjdk.org  Mon Nov 28 16:44:47 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Nov 2022 16:44:47 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v31]
In-Reply-To: <S9AFA1STby7c240-cSlvO-e0MekMt-uKHFAqUbOnoOU=.fdab60c5-eeb5-4f5e-b189-409225b7500f@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <S9AFA1STby7c240-cSlvO-e0MekMt-uKHFAqUbOnoOU=.fdab60c5-eeb5-4f5e-b189-409225b7500f@github.com>
Message-ID: <XCIXVImxWrXeXL2HyVJa4A0nrgCtpVEmEv6hX1eQSzw=.3a4ec399-5384-4849-90ac-0a8b5c48e658@github.com>

On Wed, 23 Nov 2022 17:33:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove unused Scoped interface
>   * re-add trusting of final fields in layout class implementations
>   * Fix BulkOps benchmark, which had alignment issues

Looks good on API level.

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

Marked as reviewed by pminborg (no project role).

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

From psandoz at openjdk.org  Mon Nov 28 18:30:46 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 28 Nov 2022 18:30:46 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v31]
In-Reply-To: <S9AFA1STby7c240-cSlvO-e0MekMt-uKHFAqUbOnoOU=.fdab60c5-eeb5-4f5e-b189-409225b7500f@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <S9AFA1STby7c240-cSlvO-e0MekMt-uKHFAqUbOnoOU=.fdab60c5-eeb5-4f5e-b189-409225b7500f@github.com>
Message-ID: <FKBN82tL18C-Krv3xHtlfkgomts1em20E1gFc2WKqy8=.e3570b94-7481-4742-a852-9405eb269b43@github.com>

On Wed, 23 Nov 2022 17:33:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove unused Scoped interface
>   * re-add trusting of final fields in layout class implementations
>   * Fix BulkOps benchmark, which had alignment issues

Marked as reviewed by psandoz (Reviewer).

src/java.base/share/classes/jdk/internal/foreign/FunctionDescriptorImpl.java line 57:

> 55:      * {@return the return layout (if any) associated with this function descriptor}
> 56:      */
> 57:     public final Optional<MemoryLayout> returnLayout() {

No need for `final` since class is final.

Suggestion:

    public Optional<MemoryLayout> returnLayout() {

src/java.base/share/classes/jdk/internal/foreign/SlicingAllocator.java line 33:

> 31: public final class SlicingAllocator implements SegmentAllocator {
> 32: 
> 33:     public static final long DEFAULT_BLOCK_SIZE = 4 * 1024;

Not used.

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

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

From mcimadamore at openjdk.org  Mon Nov 28 19:29:08 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Nov 2022 19:29:08 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v32]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <cJ48CQwDtj894fCv2OVZb0czHdZeP0onHPA8KDIEyjg=.1c2bf974-6039-4cf4-894c-1329f173efbc@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/97168155..6699ad99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=30-31

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

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

From psandoz at openjdk.org  Mon Nov 28 19:39:58 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 28 Nov 2022 19:39:58 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
Message-ID: <B-tQrys_c-uYlVvn2cQndNDyrtSNQHXOp9Tr3F5QgKs=.7f42ee26-370e-4018-bc12-29e4e88f57bf@github.com>

On Mon, 28 Nov 2022 10:47:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-introduce yet another address vairable

The approach looks good, and almost the least intrusive (see comment).

src/java.base/share/classes/java/nio/Buffer.java line 838:

> 836: 
> 837:                 @Override
> 838:                 public void releaseSession(Buffer buffer, MemorySessionImpl scope) {

I prefer methods that do not expose the scope implementation so access is limited to just to the acquire/release methods, but i am unsure of the performance implications. These methods might not reliably inline, and we may need to ensure that first (which is also separately a good thing). I think it requires that the shared secret fields are stable and that there is only one implementation of `JavaNioAccess`, which there is, but we can enforce via sealing. Something to consider as a further iteration.

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

Marked as reviewed by psandoz (Reviewer).

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

From tsteele at openjdk.org  Mon Nov 28 21:06:45 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Mon, 28 Nov 2022 21:06:45 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <-tPn-83pafiAnATErF8OLTLR7BetQ77vdamo4UOofXQ=.69337422-e19c-45bb-bd0a-60fff93094de@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
 <N6C6XSpbxeWMpSX6JUmHJeL5w1CbwDgLKkO4FSnTQRQ=.4922a76e-0856-4067-989d-bc23bb17917f@github.com>
 <JtoPU2zYSSyhgd8PfzdlhDOTaQD07TJzD3T0Q_usvtY=.8c02509d-b40e-446c-a270-7e51fd9e42c1@github.com>
 <zcEE4RIpxUHOmo-DgI3JBe2YSmItGsxGplBvFq6d13s=.a612940e-362c-45de-bcff-3d4b37252461@github.com>
 <-tPn-83pafiAnATErF8OLTLR7BetQ77vdamo4UOofXQ=.69337422-e19c-45bb-bd0a-60fff93094de@github.com>
Message-ID: <eogntycYJrctlcbljm3DlvVhXfGPfyKxfmR5Rwp7ur8=.8ef5af6f-9ccb-40fb-983f-c44350c69772@github.com>

On Thu, 24 Nov 2022 08:59:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to run this on the AIX system and paste in the output?

On AIX:

2022-11-28T16:12:18.277871263Z
2022-11-28T16:12:18.281290513Z


On Linux x86_64:

2022-11-28T16:17:34.006071133Z
2022-11-28T16:17:34.015071329Z



> That is, it looks like AIX may use st_mtime_n rather than st_mtimespec.tv_nsec.

It looks to me like this is just a difference in naming, and that both refer to nanosecond resolution.

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

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

From prr at openjdk.org  Mon Nov 28 23:27:55 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 28 Nov 2022 23:27:55 GMT
Subject: RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
Message-ID: <JtvVGemz10-N9otE53_d4qnDX55iqR82daQ2EAFXdTM=.983f7514-3c5b-40af-a60d-0210cfec43a4@github.com>

On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove updates from unexported files

src/java.desktop/share/classes/java/awt/package-info.java line 58:

> 56:  *     <li><a href="doc-files/Modality.html">The AWT Modality</a>
> 57:  *     <li><a href="{@docRoot}/../specs/AWT_Native_Interface.html">
> 58:  *                  The Java AWT Native Interface (JAWT)</a>

Why only 1 of these 3 ?

src/java.desktop/share/classes/java/awt/package-info.java line 62:

> 60:  *
> 61:  * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide
> 62:  * @since 1.0

I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ?
But I also wonder why only the native_interface spec was added and not the other two ?

src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226:

> 224:      * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3
> 225:      * @see #TAG_COMPRESSION
> 226:      * @see <a href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a>

Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ?

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

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

From jpai at openjdk.org  Tue Nov 29 07:15:29 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 29 Nov 2022 07:15:29 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <vK98Lx7Y5Z9zH6ag4bSmnjZoKBBsJ_NwfEFogZGW8Uo=.202b0824-938f-4e2b-9694-53c6e9b433dc@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <vK98Lx7Y5Z9zH6ag4bSmnjZoKBBsJ_NwfEFogZGW8Uo=.202b0824-938f-4e2b-9694-53c6e9b433dc@github.com>
Message-ID: <4Nin6zpfdp7UunnhCgfTR5eIfXHz_C9huT_eieZgZeI=.6cead755-8a26-4728-b7e4-8239cb7ca51e@github.com>

On Wed, 16 Nov 2022 08:11:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> In our CI system `test/jdk/java/nio/file/WatchService/Move.java` appears to time out consistently, although I have not seen it happen on my local machine.
>> 
>> I've been backed up with other things and finally getting to look at this more closely. For testing, I tried both release and debug builds across a range of macOS releases on both x64 and aarch64. Unfortunately there is a lot of timeouts and intermittent failures and across quite a range of macOS releases (from 10.15 to 12.2).
>> 
>> The most frequent failure seems to be the testOverflowEvent test in LotsOfEvents.  Here's an example failure:
>> 
>> ----------System.out:(1/47)----------
>> Seed from RandomFactory = 1932318894124342221L
>> ----------System.err:(12/655)----------
>> java.lang.RuntimeException: Key not signalled (unexpected)
>> 	at LotsOfEvents.drainAndCheckOverflowEvents(LotsOfEvents.java:105)
>> 	at LotsOfEvents.testOverflowEvent(LotsOfEvents.java:78)
>> 	at LotsOfEvents.main(LotsOfEvents.java:51)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>> 	at java.base/java.lang.Thread.run(Thread.java:1591)
>
>> @AlanBateman still can't reproduce any of that on my hardware, so I added some tracing so that next time tests are run we can at least see what's happening.
> 
> LotsOfEvents.java on macOS 12.2
> 
> ----------stdout:(7/337)----------
> WatchService: get run loop -> 600003a5c500
> WatchService: running run loop 600003a5c500
> WatchService: created event stream 101105150
> WatchService: scheduled event stream 101105150 on run loop 600003a5c500
> WatchService: running run loop 600003a5c500
> WatchService: stopped event stream 101105150
> WatchService: stopped run loop 600003a5c500
> ----------System.out:(10/421)----------
> Seed from RandomFactory = 5027502271796047304L
> WatchService: Run loop 600003a5c500 - waiting...
> WatchService: Run loop 600003a5c500 - starting...
> Test: dir.register - start
> WatchService: Run loop 600003a5c500 - waiting for event source...
> Test: dir.register - done
> WatchService: Run loop 600003a5c500 - starting...
> Test: created files
> Test: About to poll
> WatchService: Run loop 600003a5c500 - waiting for event source...
> ----------System.err:(12/655)----------
> java.lang.RuntimeException: Key not signalled (unexpected)
> 	at LotsOfEvents.drainAndCheckOverflowEvents(LotsOfEvents.java:112)
> 	at LotsOfEvents.testOverflowEvent(LotsOfEvents.java:84)
> 	at LotsOfEvents.main(LotsOfEvents.java:51)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:1591)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException
> JavaTest Message: shutting down test
> 
> result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Key not signalled (unexpected)
> 
> 
> DeleteInterference.java also  on macOS 12.2, this one is a timeout:
> 
> open 292 end
> open 293 begin
> WatchService: Run loop 6000004a9000 - waiting...
> WatchService: Run loop 6000004a9000 - starting...
> WatchService: Run loop 6000004a9000 - waiting for event source...
> open 293 end
> open 294 begin
> WatchService: Run loop 6000004ade00 - waiting...
> WatchService: Run loop 6000004ade00 - starting...
> WatchService: Run loop 6000004ade00 - waiting for event source...
> WatchService: Run loop 6000004ade00 - starting...
> WatchService: Run loop 60000
> result: Error. Agent error: java.lang.Exception: Agent 8 timed out with a timeout of 480 seconds; check console log for any additional details
> 
> test result: Error. Agent error: java.lang.Exception: Agent 8 timed out with a timeout of 480 seconds; check console log for any additional details
> 
> 
> The .jtr are huge due to all the tracing.

> @AlanBateman Thank you for the log. I see all the right calls, but I don't see any events coming in from the OS.
> 
> I'm afraid this is the line beyond which I can't tread; there seem to be instances where [certain directories don't generate FSEvents](https://github.com/livereload/livereload-site/blob/master/livereload.com/_articles/troubleshooting/os-x-fsevents-bug-may-prevent-monitoring-of-certain-folders.md), there's even a [tool](https://github.com/andreyvit/find-fsevents-bugs) to find those. Unfortunately, I know nothing beyond what was said on those pages.

FWIW - I am seeing the same exceptions that Alan mentioned across various WatchService related tests on different versions of macos, with the changes in this PR. That isn't too surprising because I use the same infrastructure as Alan to test this. Looking at some of the debug logs that I have access too, it does appear that the OS itself isn't generating those events (or is generating it in a very delayed manner). I see that in your changes, you use a latency of `0.5` seconds, but the delay I'm seeing in the logs is far greater than that. I'm not yet sure what's going on.
While reviewing the native APIs being used in this change, I noticed that `FSEventStreamScheduleWithRunLoop` is called in the implementation. The macOS documentation for this API states that this is deprecated (since macOS 10.5) https://developer.apple.com/documentation/coreservices/1447824-fseventstreamschedulewithrunloop. Should we instead be implementing this using some other APIs that macOS recommends?

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

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

From pminborg at openjdk.org  Tue Nov 29 07:57:23 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Nov 2022 07:57:23 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v16]
In-Reply-To: <B-tQrys_c-uYlVvn2cQndNDyrtSNQHXOp9Tr3F5QgKs=.7f42ee26-370e-4018-bc12-29e4e88f57bf@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <R1kaAvBBfrYrcZaSwQLZBlGDqVmQoIhSM_mxW-lggFM=.123c7477-5085-4998-a3bb-3aa07b71de95@github.com>
 <B-tQrys_c-uYlVvn2cQndNDyrtSNQHXOp9Tr3F5QgKs=.7f42ee26-370e-4018-bc12-29e4e88f57bf@github.com>
Message-ID: <RiwpEqwEUkQFRs2nQvTR75dUEXQtiyJY9TQ2MJ8jTvA=.b052a5de-fa63-43e2-a7b8-51ff4b87bec1@github.com>

On Mon, 28 Nov 2022 19:35:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I prefer methods that do not expose the scope implementation so access is limited to just to the acquire/release methods, but i am unsure of the performance implications. These methods might not reliably inline, and we may need to ensure that first (which is also separately a good thing). I think it requires that the shared secret fields are stable and that there is only one implementation of `JavaNioAccess`, which there is, but we can enforce via sealing. Something to consider as a further iteration.

I agree. A similar approach was done in a previous incarnation of the PR whereby we exposed a `ScopeAcqusition` that held an internal copy of the buffer and provided means to release. We feared that would cause performance regression. But your comment made me think of another way of doing acquire/release which would not expose the session and that would always be performant. I will explore this idea a bit more.

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

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

From mkartashev at openjdk.org  Tue Nov 29 08:47:27 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 29 Nov 2022 08:47:27 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <4Nin6zpfdp7UunnhCgfTR5eIfXHz_C9huT_eieZgZeI=.6cead755-8a26-4728-b7e4-8239cb7ca51e@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <vK98Lx7Y5Z9zH6ag4bSmnjZoKBBsJ_NwfEFogZGW8Uo=.202b0824-938f-4e2b-9694-53c6e9b433dc@github.com>
 <4Nin6zpfdp7UunnhCgfTR5eIfXHz_C9huT_eieZgZeI=.6cead755-8a26-4728-b7e4-8239cb7ca51e@github.com>
Message-ID: <aJJRaOyEdixdYCyOFAJdyufruS5pBZs31t73CVnhWPM=.e00f9e2d-2273-416f-a1ac-286543be1aae@github.com>

On Tue, 29 Nov 2022 07:13:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I see that in your changes, you use a latency of 0.5 seconds, but the delay I'm seeing in the logs is far greater than that.

This "latency" argument is passed to `FSEventStreamCreate` and is used for to group a (potentially large) number of events:

> "The number of seconds the service should wait after hearing about an event from the kernel before passing it along to the client via its callback. Specifying a larger value may result in more effective temporal coalescing, resulting in fewer callbacks and greater overall efficiency." ([source](https://developer.apple.com/documentation/coreservices/1443980-fseventstreamcreate?language=objc)).

In our case, we don't get even the first event in a hypothetical sequence, so latency does not seem to be involved here.

> FSEventStreamScheduleWithRunLoop is called in the implementation. The macOS documentation for this API states that this is deprecated (since macOS 10.5) 

This is indeed the case. Let me look into rewriting this, perhaps.

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

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

From pminborg at openjdk.org  Tue Nov 29 09:40:58 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Nov 2022 09:40:58 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
Message-ID: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>

> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
> 
> Design choices in this PR:
> 
> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
> 
> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
> 
> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
> 
> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
> 
> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
> 
> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.

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

  Remove session exposure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11260/files
  - new: https://git.openjdk.org/jdk/pull/11260/files/eedf41ae..619473ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=15-16

  Stats: 125 lines in 20 files changed: 11 ins; 13 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/11260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260

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

From mik3hall at gmail.com  Tue Nov 29 09:56:36 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 29 Nov 2022 03:56:36 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <aJJRaOyEdixdYCyOFAJdyufruS5pBZs31t73CVnhWPM=.e00f9e2d-2273-416f-a1ac-286543be1aae@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <vK98Lx7Y5Z9zH6ag4bSmnjZoKBBsJ_NwfEFogZGW8Uo=.202b0824-938f-4e2b-9694-53c6e9b433dc@github.com>
 <4Nin6zpfdp7UunnhCgfTR5eIfXHz_C9huT_eieZgZeI=.6cead755-8a26-4728-b7e4-8239cb7ca51e@github.com>
 <aJJRaOyEdixdYCyOFAJdyufruS5pBZs31t73CVnhWPM=.e00f9e2d-2273-416f-a1ac-286543be1aae@github.com>
Message-ID: <D4FCAD06-9AF8-49D5-BD40-895BCD9C2B1A@gmail.com>



> On Nov 29, 2022, at 2:47 AM, Maxim Kartashev <mkartashev at openjdk.org> wrote:
> 
> FSEventStreamCreate

This is sounding somewhat similar to the kqueue watcher I attempted. It was suggested this was due to maxing out file descriptors. Which seems plausible. What I would see was that suddenly the kernel would cease sending events at all.

https://developer.apple.com/documentation/coreservices/1443980-fseventstreamcreate <https://developer.apple.com/documentation/coreservices/1443980-fseventstreamcreate>
The number of seconds the service should wait after hearing about an event from the kernel 

Note this indicates it is still based on receiving events from the kernel. The following was my code, it shows originally I did no polling at all but changed it to do polling thinking this was a thread deadlock issue. But with polling my thread continued to run, it was the kernel that totally stopped sending events. Again this seems potentially similar to what is being described for errors here. It occurred in trying mine on the LotsOfEvents test. Maybe there would be some way you could check for this situation? The errors all seem to be timeouts when things stop happening, or I suppose happen but are missed?  

-(void)		watcherThread: (id)sender
{
	int					n;
	int 				idle_cnt = 0;
	
	struct kevent64_s   ev;
    struct timespec     timeout = { 5, 0 }; // 5 seconds timeout.
	int					theFD = queueFD;	// So we don't have to risk accessing iVars when the thread is terminated.
	struct timespec		nullts = { 1, 0 };
		
    while( keepThreadRunning )
    {
		NSAutoreleasePool*  pool = [[NSAutoreleasePool alloc] init];
		NS_DURING
//			NSLog(@"going into kevent");
			n = kevent64( queueFD, NULL, 0, &ev, 1, 0, &timeout );
//			n = kevent64( queueFD, NULL, 0, &ev, 1, 0, &nullts );
//			n = kevent64( queueFD, NULL, 0, &ev, 1, 0, NULL);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221129/53d9cca9/attachment.htm>

From mcimadamore at openjdk.org  Tue Nov 29 10:19:48 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Nov 2022 10:19:48 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <8HV7vdX-QrKG_OhlGWLwAG2uLsT8sKIbIqAce65bNWU=.68ffecbe-2065-418c-a0a5-1f0d04964717@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

This looks more symmetric, I like it. Since `acquire` was only really returning null if the underlying buffer had no associated session, I believe this rewriting preserves the semantics we had before (e.g. no accidental double releases).

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

Marked as reviewed by mcimadamore (Reviewer).

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

From mkartashev at openjdk.org  Tue Nov 29 10:47:16 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 29 Nov 2022 10:47:16 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v11]
In-Reply-To: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
Message-ID: <cPgIPh1EiOKn6DpntaPYtohSI36BRmr3ZD-c3eXmS54=.3f7681bd-5817-4685-89ac-6ac5709e9dfa@github.com>

> This is an implementation of `WatchService` based on File System Events API that is capable of generating events whenever a change occurs in an interesting directory or underneath it. Since the API naturally supports "recursive" watch, the `FILE_TREE` is supported by the watch service. 
> 
> Some things of note:
> * There's one "service" thread per `WatchService` instance that is inactive unless changes occur in the watched directory. The changes are grouped by introducing a time delay between when they occurred and when they are reported, which is controlled by the sensitivity modifier of the watch service.
> * Since FSEvents API reports directories only, the watch service keeps a snapshot (hierarchical if necessary) of the files in the directory being watched. The snapshot gets updated when an event in that directory or underneath it gets delivered. File changes are detected by comparing "last modified" time with a millisecond precision (`BasicFileAttributes.lastModifiedTime()`).
> * There is a slight complication with the move of an entire directory hierarchy: FSEvents API only reports about the containing directory of that move and not about any of the directories actually moved. There's a separate test for that (`Move.java`).
> * The code is careful not to do any I/O (such as reading the contents of a directory or attributes of a file) unless unavoidable. Any deviation from this line should be considered a bug (of, arguably, low priority).
> * The native part consists mostly of API wrappers with one exception of the callback function invoked by the system to report the events that occurred. The sole task of the function is to convert from C strings to Java strings and pass the array of affected directories to Java code. This can be rewritten if desired to make the code more future-proof.
> 
> This commit leaves `PollingWatchService` unused. I'm not sure if I should/can do anything about it. Any advice is welcomed.
> 
> ### Testing
> 
> * Tested by running `test/jdk/java/nio/file` and `test/jdk/jdk/nio` on MacOS 10.15.7 (x64) and `test/jdk/java/nio/` plus `test/jdk/jdk/nio` on MacOS 12.5.1 (aarch64).
> * Also verified that new tests pass on Linux and Windows.
> * This code (albeit in a slightly modified form) has been in use at JetBrains for around half a year and a few bugs have been found and fixed during that time period.

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

  Check FSEventStreamStart() return value

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10140/files
  - new: https://git.openjdk.org/jdk/pull/10140/files/8bed2635..4ce2f842

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10140&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10140&range=09-10

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10140.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10140/head:pull/10140

PR: https://git.openjdk.org/jdk/pull/10140

From mkartashev at openjdk.org  Tue Nov 29 10:49:15 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 29 Nov 2022 10:49:15 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v10]
In-Reply-To: <K0vkQwCONYUppMPTeeFg_v15LvT1_t8pvHVFQRtE2_g=.ee90fe13-2f26-4134-97c1-85f12fd7f79b@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <K0vkQwCONYUppMPTeeFg_v15LvT1_t8pvHVFQRtE2_g=.ee90fe13-2f26-4134-97c1-85f12fd7f79b@github.com>
Message-ID: <8BUAotMUfrGALboIh4prz1m5D-K6_2891wwT1YAFcRc=.576207f8-74ff-435a-a193-efa51fa70553@github.com>

On Tue, 15 Nov 2022 10:00:29 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> This is an implementation of `WatchService` based on File System Events API that is capable of generating events whenever a change occurs in an interesting directory or underneath it. Since the API naturally supports "recursive" watch, the `FILE_TREE` is supported by the watch service. 
>> 
>> Some things of note:
>> * There's one "service" thread per `WatchService` instance that is inactive unless changes occur in the watched directory. The changes are grouped by introducing a time delay between when they occurred and when they are reported, which is controlled by the sensitivity modifier of the watch service.
>> * Since FSEvents API reports directories only, the watch service keeps a snapshot (hierarchical if necessary) of the files in the directory being watched. The snapshot gets updated when an event in that directory or underneath it gets delivered. File changes are detected by comparing "last modified" time with a millisecond precision (`BasicFileAttributes.lastModifiedTime()`).
>> * There is a slight complication with the move of an entire directory hierarchy: FSEvents API only reports about the containing directory of that move and not about any of the directories actually moved. There's a separate test for that (`Move.java`).
>> * The code is careful not to do any I/O (such as reading the contents of a directory or attributes of a file) unless unavoidable. Any deviation from this line should be considered a bug (of, arguably, low priority).
>> * The native part consists mostly of API wrappers with one exception of the callback function invoked by the system to report the events that occurred. The sole task of the function is to convert from C strings to Java strings and pass the array of affected directories to Java code. This can be rewritten if desired to make the code more future-proof.
>> 
>> This commit leaves `PollingWatchService` unused. I'm not sure if I should/can do anything about it. Any advice is welcomed.
>> 
>> ### Testing
>> 
>> * Tested by running `test/jdk/java/nio/file` and `test/jdk/jdk/nio` on MacOS 10.15.7 (x64) and `test/jdk/java/nio/` plus `test/jdk/jdk/nio` on MacOS 12.5.1 (aarch64).
>> * Also verified that new tests pass on Linux and Windows.
>> * This code (albeit in a slightly modified form) has been in use at JetBrains for around half a year and a few bugs have been found and fixed during that time period.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Temporary auxiliary tracing to aid in debugging test failures

I just noticed a curious line in the documentation for `FSEventStreamStart()`:
>  It ought to always succeed, but in the event it does not then your code should fall back to performing recursive scans of the directories of interest as appropriate.

So I added a check for the return value of `FSEventStreamStart()`; if anyone who has seen tests failing (@AlanBateman @jaikiran) could please re-run some of them to see if an `InternalError` gets thrown, we can at least establish that the fallback mechanism the documentation talks about actually has to be implemented, which will give us a way to move forward.

Thanks in advance!

-------------

PR: https://git.openjdk.org/jdk/pull/10140

From alanb at openjdk.org  Tue Nov 29 11:21:59 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Nov 2022 11:21:59 GMT
Subject: RFR: 8297275: WatchService delay with PollingWatchService causes
 test failures
In-Reply-To: <eogntycYJrctlcbljm3DlvVhXfGPfyKxfmR5Rwp7ur8=.8ef5af6f-9ccb-40fb-983f-c44350c69772@github.com>
References: <hGyJPQvjwj75O48LigDJVEPhToCbeNo-01F2r6g4tgQ=.f539abdb-d0ad-4f20-bc6b-6b79034a1cf5@github.com>
 <N6C6XSpbxeWMpSX6JUmHJeL5w1CbwDgLKkO4FSnTQRQ=.4922a76e-0856-4067-989d-bc23bb17917f@github.com>
 <JtoPU2zYSSyhgd8PfzdlhDOTaQD07TJzD3T0Q_usvtY=.8c02509d-b40e-446c-a270-7e51fd9e42c1@github.com>
 <zcEE4RIpxUHOmo-DgI3JBe2YSmItGsxGplBvFq6d13s=.a612940e-362c-45de-bcff-3d4b37252461@github.com>
 <-tPn-83pafiAnATErF8OLTLR7BetQ77vdamo4UOofXQ=.69337422-e19c-45bb-bd0a-60fff93094de@github.com>
 <eogntycYJrctlcbljm3DlvVhXfGPfyKxfmR5Rwp7ur8=.8ef5af6f-9ccb-40fb-983f-c44350c69772@github.com>
Message-ID: <zkIEc2eHqEkEIc3Q05nbtyI0YCrjZTvsUxwc7oWWzEs=.ac108227-4626-41a6-8751-ce5eb10b82f4@github.com>

On Mon, 28 Nov 2022 20:52:48 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> > Would it be possible to run this on the AIX system and paste in the output?
> 
> On AIX:
> 
> ```
> 2022-11-28T16:12:18.277871263Z
> 2022-11-28T16:12:18.281290513Z
> ```

Okay, so this means you've got high precision on the last modification time. So for these values it means that registering the directory will read initial time stamp as "2022-11-28T16:12:18.277871263Z", recording it in milliseconds. The file is modified (append in the example) and a short time later the WatchService should read the time stamp as "022-11-28T16:12:18.281290513Z", see that it has changed, and queue ENTRY_MODIFY event. So now I think we are back to why this is not happening on some AIX systems. Does it always fail on specific systems or it is intermittent? Any mount options or other config that enables or disables higher precision time stamps?

-------------

PR: https://git.openjdk.org/jdk/pull/10824

From alanb at openjdk.org  Tue Nov 29 14:25:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Nov 2022 14:25:53 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <imPDtE3v_kdFiu-MpQbYCrhrZ3dUWEL5mFrIQL9jYNQ=.df5a4f44-64eb-4ded-94a8-967140a84ac6@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From psandoz at openjdk.org  Tue Nov 29 16:21:25 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 29 Nov 2022 16:21:25 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <V3gcPvdGTNp_x6EiidGcs3Lw28BZiT29_JmKI_WKv24=.6570b117-67d4-4890-be6a-7cbcbf58fbe7@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From bpb at openjdk.org  Tue Nov 29 18:08:26 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 29 Nov 2022 18:08:26 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <cvaemJgKtEOadHrbrClGy4eT618IkjsKXGi2NDyWTos=.2e0dc1d1-609b-4d75-aa90-020193c2896d@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From jpai at openjdk.org  Wed Nov 30 00:40:21 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:40:21 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
 <nkF56VNUGNwkw6TU9okcVp1IkdvOwVa77FFv2IYC2uQ=.e90eb3c7-ad15-4ea2-8e52-28d462659130@github.com>
Message-ID: <yt80pFqXzOAv8ZoCHgjvBBruV1kcdXmPt-xEFPqfrr8=.ad0cd2c4-b730-4362-b031-337991eff415@github.com>

On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
>> 
>> I'll raise separate PRs in the other remaining areas from that other PR.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment - don't change WithHelperPublisher.java

Thank you everyone for the reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From jpai at openjdk.org  Wed Nov 30 00:40:21 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 00:40:21 GMT
Subject: Integrated: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni
In-Reply-To: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
References: <on2XO-4HCkV7Eq_C2_EINV7PWhpht-kiaeYC7qOXlQk=.ccb9c72c-1341-436f-be47-80a514630174@github.com>
Message-ID: <E09ZXv_6AoFNPWbC2-vUhfflo09LMQMBXc5BoX-Pe7c=.8d7cafee-51cb-4f6d-b927-cef4ef4d06d0@github.com>

On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled.
> 
> I'll raise separate PRs in the other remaining areas from that other PR.

This pull request has now been integrated.

Changeset: 0ce18272
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ce182723b8d3a98c71c1b71fa1d3f5a7479fba8
Stats:     20 lines in 19 files changed: 0 ins; 0 del; 20 mod

8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Co-authored-by: Michael Ernst <mernst at openjdk.org>
Reviewed-by: alanb, lancea, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/11385

From jpai at openjdk.org  Wed Nov 30 03:22:24 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 03:22:24 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v10]
In-Reply-To: <8BUAotMUfrGALboIh4prz1m5D-K6_2891wwT1YAFcRc=.576207f8-74ff-435a-a193-efa51fa70553@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <K0vkQwCONYUppMPTeeFg_v15LvT1_t8pvHVFQRtE2_g=.ee90fe13-2f26-4134-97c1-85f12fd7f79b@github.com>
 <8BUAotMUfrGALboIh4prz1m5D-K6_2891wwT1YAFcRc=.576207f8-74ff-435a-a193-efa51fa70553@github.com>
Message-ID: <kkQ_QQyU9XhIyYAXSNR8fBiq5Mz0Vey7neGDxHTLNQk=.afc68a05-6492-4b83-9b6f-550a760a8c94@github.com>

On Tue, 29 Nov 2022 10:47:03 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> I just noticed a curious line in the documentation for `FSEventStreamStart()`:
> 
> > It ought to always succeed, but in the event it does not then your code should fall back to performing recursive scans of the directories of interest as appropriate.
> 
> So I added a check for the return value of `FSEventStreamStart()`; if anyone who has seen tests failing (@AlanBateman @jaikiran) could please re-run some of them to see if an `InternalError` gets thrown, we can at least establish that the fallback mechanism the documentation talks about actually has to be implemented, which will give us a way to move forward.
> 
> Thanks in advance!

I gave this latest state of the PR a try and the tests continue to fail across various versions of the macos, like previously. I even noticed a JVM crash:


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fff206a1b2e, pid=xxxx, tid=xxxx
#
# JRE version: Java(TM) SE Runtime Environment (20.0) (build 20-internal-2022-11-29)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20-internal-2022-11-29, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
# Problematic frame:
C [CoreFoundation+0x14ab2e]  _CFGetNonObjCTypeID+0xa

(it could be that the JVM crash was present even in previous version of this PR before your latest commit - I hadn't looked into all log files).

-------------

PR: https://git.openjdk.org/jdk/pull/10140

From darcy at openjdk.org  Wed Nov 30 04:58:24 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 30 Nov 2022 04:58:24 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v32]
In-Reply-To: <cJ48CQwDtj894fCv2OVZb0czHdZeP0onHPA8KDIEyjg=.1c2bf974-6039-4cf4-894c-1329f173efbc@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <cJ48CQwDtj894fCv2OVZb0czHdZeP0onHPA8KDIEyjg=.1c2bf974-6039-4cf4-894c-1329f173efbc@github.com>
Message-ID: <cLXbImXuUZk90CMUs_9DM_ZAEWTsIxqU21HkQuvq32Q=.0c61d46d-2ea3-4b6d-8c01-c9e4b7a8fc9d@github.com>

On Mon, 28 Nov 2022 19:29:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/java/lang/foreign/Linker.java line 288:

> 286: 
> 287:         /**
> 288:          * {@return A linker option used to denote the index of the first variadic argument layout in a

Typo: "A linker" vs "a linker"

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From mkartashev at openjdk.org  Wed Nov 30 08:24:23 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 30 Nov 2022 08:24:23 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v10]
In-Reply-To: <kkQ_QQyU9XhIyYAXSNR8fBiq5Mz0Vey7neGDxHTLNQk=.afc68a05-6492-4b83-9b6f-550a760a8c94@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <K0vkQwCONYUppMPTeeFg_v15LvT1_t8pvHVFQRtE2_g=.ee90fe13-2f26-4134-97c1-85f12fd7f79b@github.com>
 <8BUAotMUfrGALboIh4prz1m5D-K6_2891wwT1YAFcRc=.576207f8-74ff-435a-a193-efa51fa70553@github.com>
 <kkQ_QQyU9XhIyYAXSNR8fBiq5Mz0Vey7neGDxHTLNQk=.afc68a05-6492-4b83-9b6f-550a760a8c94@github.com>
Message-ID: <GFQf4YrxrmTQmOxS34-LyRpH-GUhfenn3uR3IDwxoxY=.af1d3f7a-b8e2-4748-a53e-0d06f9cbbc2e@github.com>

On Wed, 30 Nov 2022 03:20:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I just noticed a curious line in the documentation for `FSEventStreamStart()`:
>>>  It ought to always succeed, but in the event it does not then your code should fall back to performing recursive scans of the directories of interest as appropriate.
>> 
>> So I added a check for the return value of `FSEventStreamStart()`; if anyone who has seen tests failing (@AlanBateman @jaikiran) could please re-run some of them to see if an `InternalError` gets thrown, we can at least establish that the fallback mechanism the documentation talks about actually has to be implemented, which will give us a way to move forward.
>> 
>> Thanks in advance!
>
>> I just noticed a curious line in the documentation for `FSEventStreamStart()`:
>> 
>> > It ought to always succeed, but in the event it does not then your code should fall back to performing recursive scans of the directories of interest as appropriate.
>> 
>> So I added a check for the return value of `FSEventStreamStart()`; if anyone who has seen tests failing (@AlanBateman @jaikiran) could please re-run some of them to see if an `InternalError` gets thrown, we can at least establish that the fallback mechanism the documentation talks about actually has to be implemented, which will give us a way to move forward.
>> 
>> Thanks in advance!
> 
> I gave this latest state of the PR a try and the tests continue to fail across various versions of the macos, like previously. I even noticed a JVM crash:
> 
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007fff206a1b2e, pid=xxxx, tid=xxxx
> #
> # JRE version: Java(TM) SE Runtime Environment (20.0) (build 20-internal-2022-11-29)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20-internal-2022-11-29, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
> # Problematic frame:
> C [CoreFoundation+0x14ab2e]  _CFGetNonObjCTypeID+0xa
> 
> (it could be that the JVM crash was present even in previous version of this PR before your latest commit - I hadn't looked into all log files).

@jaikiran The tests were supposed to continue to fail, but this time there was a chance to diagnose the failure by checking if an InternalError was thrown from my latest commit. Have you seen any in the test logs?

-------------

PR: https://git.openjdk.org/jdk/pull/10140

From jpai at openjdk.org  Wed Nov 30 11:32:26 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 11:32:26 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v10]
In-Reply-To: <kkQ_QQyU9XhIyYAXSNR8fBiq5Mz0Vey7neGDxHTLNQk=.afc68a05-6492-4b83-9b6f-550a760a8c94@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <K0vkQwCONYUppMPTeeFg_v15LvT1_t8pvHVFQRtE2_g=.ee90fe13-2f26-4134-97c1-85f12fd7f79b@github.com>
 <8BUAotMUfrGALboIh4prz1m5D-K6_2891wwT1YAFcRc=.576207f8-74ff-435a-a193-efa51fa70553@github.com>
 <kkQ_QQyU9XhIyYAXSNR8fBiq5Mz0Vey7neGDxHTLNQk=.afc68a05-6492-4b83-9b6f-550a760a8c94@github.com>
Message-ID: <FYy-PvEDYvz61PrqvzwxsMt4dy8N3IDXBpXxaHPX8uQ=.082466eb-6e61-45de-a176-b0c572a58163@github.com>

On Wed, 30 Nov 2022 03:20:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I just noticed a curious line in the documentation for `FSEventStreamStart()`:
>>>  It ought to always succeed, but in the event it does not then your code should fall back to performing recursive scans of the directories of interest as appropriate.
>> 
>> So I added a check for the return value of `FSEventStreamStart()`; if anyone who has seen tests failing (@AlanBateman @jaikiran) could please re-run some of them to see if an `InternalError` gets thrown, we can at least establish that the fallback mechanism the documentation talks about actually has to be implemented, which will give us a way to move forward.
>> 
>> Thanks in advance!
>
>> I just noticed a curious line in the documentation for `FSEventStreamStart()`:
>> 
>> > It ought to always succeed, but in the event it does not then your code should fall back to performing recursive scans of the directories of interest as appropriate.
>> 
>> So I added a check for the return value of `FSEventStreamStart()`; if anyone who has seen tests failing (@AlanBateman @jaikiran) could please re-run some of them to see if an `InternalError` gets thrown, we can at least establish that the fallback mechanism the documentation talks about actually has to be implemented, which will give us a way to move forward.
>> 
>> Thanks in advance!
> 
> I gave this latest state of the PR a try and the tests continue to fail across various versions of the macos, like previously. I even noticed a JVM crash:
> 
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007fff206a1b2e, pid=xxxx, tid=xxxx
> #
> # JRE version: Java(TM) SE Runtime Environment (20.0) (build 20-internal-2022-11-29)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20-internal-2022-11-29, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
> # Problematic frame:
> C [CoreFoundation+0x14ab2e]  _CFGetNonObjCTypeID+0xa
> 
> (it could be that the JVM crash was present even in previous version of this PR before your latest commit - I hadn't looked into all log files).

> @jaikiran The tests were supposed to continue to fail, but this time there was a chance to diagnose the failure by checking if an InternalError was thrown from my latest commit. Have you seen any in the test logs?

What I meant in my earlier comment was the tests failed with the same errors/timeouts as previously. There was no InternalError thrown.

-------------

PR: https://git.openjdk.org/jdk/pull/10140

From Engineer.Fouad at hotmail.com  Wed Nov 30 12:19:28 2022
From: Engineer.Fouad at hotmail.com (Fouad Almalki)
Date: Wed, 30 Nov 2022 12:19:28 +0000
Subject: UNIX domain datagram support in Java
Message-ID: <DB9P190MB201123BDA097A335D35DCDA881159@DB9P190MB2011.EURP190.PROD.OUTLOOK.COM>

Hi,

Is there a plan to support UNIX domain datagram in Java?

It seems that https://openjdk.org/jeps/380 does not support datagram.
JEP 380: Unix-Domain Socket Channels<https://openjdk.org/jeps/380>
Summary. Add Unix-domain (AF_UNIX) socket support to the socket channel and server-socket channel APIs in the java.nio.channels package.Extend the inherited channel mechanism to support Unix-domain socket channels and server socket channels.. Goals. Unix-domain sockets are used for inter-process communication (IPC) on the same host. They are similar to TCP/IP sockets in most respects, except ...
openjdk.org

One of the usages is to be able to notify systemd service manager about start-up completion without the need of JNI to invoke a system call.

https://github.com/quarkusio/quarkus/issues/29107#issuecomment-1328173833
[https://opengraph.githubassets.com/174176286ca434859f5f405db6d4426b554154d36f38347e41b3b3cbd3542168/quarkusio/quarkus/issues/29107]<https://github.com/quarkusio/quarkus/issues/29107#issuecomment-1328173833>
Integrate Linux systemd-notify with Quarkus ? Issue #29107 ? quarkusio/quarkus<https://github.com/quarkusio/quarkus/issues/29107#issuecomment-1328173833>
Description Systemd is a popular service manager on Linux OS that manages starting/stopping services. When a service unit file is configured to be of type notify: [Service] Type=notify it is expect...
github.com
?
?


Thanks,
Fouad Almalki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221130/884515ed/attachment-0001.htm>

From mcimadamore at openjdk.org  Wed Nov 30 12:30:50 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Nov 2022 12:30:50 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v33]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <G74SrqEb7pdRn_g1aTtWKrfhvY-Cn6ikXembTCHRcyg=.3e68ccfc-7a98-481e-8e76-cf36704e39a8@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Polish javadoc:
  * Make sure that first para of class javadoc is succinct and descriptive
  * Remove references to "access" var handle or "memory segment view" var handle (just use var handle)
  * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para.
  * Other minor typos fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/6699ad99..5a75118b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=31-32

  Stats: 59 lines in 10 files changed: 19 ins; 18 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

PR: https://git.openjdk.org/jdk/pull/10872

From michael.x.mcmahon at oracle.com  Wed Nov 30 12:57:11 2022
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 30 Nov 2022 12:57:11 +0000
Subject: UNIX domain datagram support in Java
In-Reply-To: <DB9P190MB201123BDA097A335D35DCDA881159@DB9P190MB2011.EURP190.PROD.OUTLOOK.COM>
References: <DB9P190MB201123BDA097A335D35DCDA881159@DB9P190MB2011.EURP190.PROD.OUTLOOK.COM>
Message-ID: <456784b5-dcfc-41bb-4fde-49e8a97f5698@oracle.com>

Hi,

There is no plan to do this currently. But, I created a bug issue to 
track it at (https://bugs.openjdk.org/browse/JDK-8297837).

It might make sense to do it some time for completeness and the fact 
that no new API would be required to support it.

- Michael.

On 30/11/2022 12:19, Fouad Almalki wrote:
> Hi,
>
> Is there a plan to support UNIX domain datagram in Java?
>
> It seems thathttps://openjdk.org/jeps/380  does not support datagram.
> JEP 380: Unix-Domain Socket Channels<https://openjdk.org/jeps/380>
> Summary. Add Unix-domain (AF_UNIX) socket support to the socket channel and server-socket channel APIs in the java.nio.channels package.Extend the inherited channel mechanism to support Unix-domain socket channels and server socket channels.. Goals. Unix-domain sockets are used for inter-process communication (IPC) on the same host. They are similar to TCP/IP sockets in most respects, except ...
> openjdk.org
>
> One of the usages is to be able to notify systemd service manager about start-up completion without the need of JNI to invoke a system call.
>
> https://github.com/quarkusio/quarkus/issues/29107#issuecomment-1328173833
> [https://opengraph.githubassets.com/174176286ca434859f5f405db6d4426b554154d36f38347e41b3b3cbd3542168/quarkusio/quarkus/issues/29107]<https://github.com/quarkusio/quarkus/issues/29107#issuecomment-1328173833>
> Integrate Linux systemd-notify with Quarkus ? Issue #29107 ? quarkusio/quarkus<https://github.com/quarkusio/quarkus/issues/29107#issuecomment-1328173833>
> Description Systemd is a popular service manager on Linux OS that manages starting/stopping services. When a service unit file is configured to be of type notify: [Service] Type=notify it is expect...
> github.com
> ?
> ?
>
>
> Thanks,
> Fouad Almalki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221130/a1d90cbf/attachment.htm>

From mik3hall at gmail.com  Wed Nov 30 13:18:19 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 30 Nov 2022 07:18:19 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <4Nin6zpfdp7UunnhCgfTR5eIfXHz_C9huT_eieZgZeI=.6cead755-8a26-4728-b7e4-8239cb7ca51e@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <vK98Lx7Y5Z9zH6ag4bSmnjZoKBBsJ_NwfEFogZGW8Uo=.202b0824-938f-4e2b-9694-53c6e9b433dc@github.com>
 <4Nin6zpfdp7UunnhCgfTR5eIfXHz_C9huT_eieZgZeI=.6cead755-8a26-4728-b7e4-8239cb7ca51e@github.com>
Message-ID: <432C7D3E-715C-488E-B183-F4B540336427@gmail.com>



> On Nov 29, 2022, at 1:15 AM, Jaikiran Pai <jpai at openjdk.org> wrote:
> 
> That isn't too surprising because I use the same infrastructure as Alan to test this.

I assume this infrastructure is not generally available? 
Not being able to reproduce the errors could make fixing very difficult.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221130/b97a5990/attachment-0001.htm>

From mik3hall at gmail.com  Wed Nov 30 13:31:33 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 30 Nov 2022 07:31:33 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
Message-ID: <9CB76C25-7A7E-4DE5-9E9B-ED28F244AFD2@gmail.com>



> On Nov 13, 2022, at 9:31 AM, Alan Bateman <alanb at openjdk.org> wrote:
> 
> Unfortunately there is a lot of timeouts and intermittent failures and across quite a range of macOS releases (from 10.15 to 12.2).

Are there any errors after 12.2. I am 12.6. I am not sure what Maxim is. Is it possible it was an Apple issue that is fixed in recent releases?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221130/aa4eaa0a/attachment.htm>

From maxim.kartashev at jetbrains.com  Wed Nov 30 13:59:11 2022
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Wed, 30 Nov 2022 16:59:11 +0300
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <9CB76C25-7A7E-4DE5-9E9B-ED28F244AFD2@gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <9CB76C25-7A7E-4DE5-9E9B-ED28F244AFD2@gmail.com>
Message-ID: <CAG0Tb0hKiWPpUtLWakWLoQhc-6aK6bHOoCr4AYLVR9h6gZ6KGg@mail.gmail.com>

FWIW I'm on 10.15

On Wed, Nov 30, 2022 at 4:31 PM Michael Hall <mik3hall at gmail.com> wrote:

>
>
> On Nov 13, 2022, at 9:31 AM, Alan Bateman <alanb at openjdk.org> wrote:
>
> Unfortunately there is a lot of timeouts and intermittent failures and
> across quite a range of macOS releases (from 10.15 to 12.2).
>
>
> Are there any errors after 12.2. I am 12.6. I am not sure what Maxim is.
> Is it possible it was an Apple issue that is fixed in recent releases?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221130/0c1b8e78/attachment.htm>

From mkartashev at openjdk.org  Wed Nov 30 14:00:27 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 30 Nov 2022 14:00:27 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v10]
In-Reply-To: <FYy-PvEDYvz61PrqvzwxsMt4dy8N3IDXBpXxaHPX8uQ=.082466eb-6e61-45de-a176-b0c572a58163@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <K0vkQwCONYUppMPTeeFg_v15LvT1_t8pvHVFQRtE2_g=.ee90fe13-2f26-4134-97c1-85f12fd7f79b@github.com>
 <8BUAotMUfrGALboIh4prz1m5D-K6_2891wwT1YAFcRc=.576207f8-74ff-435a-a193-efa51fa70553@github.com>
 <kkQ_QQyU9XhIyYAXSNR8fBiq5Mz0Vey7neGDxHTLNQk=.afc68a05-6492-4b83-9b6f-550a760a8c94@github.com>
 <FYy-PvEDYvz61PrqvzwxsMt4dy8N3IDXBpXxaHPX8uQ=.082466eb-6e61-45de-a176-b0c572a58163@github.com>
Message-ID: <aPo22RBF75dw4FSOE8EgV4a3tOrMQoOKAoTzjW2-WQQ=.a654d873-0c04-43a8-8b97-c6243495028a@github.com>

On Wed, 30 Nov 2022 11:28:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> What I meant in my earlier comment was the tests failed with the same errors/timeouts as previously. There was no InternalError thrown.

Thanks! No luck, then...

-------------

PR: https://git.openjdk.org/jdk/pull/10140

From jpai at openjdk.org  Wed Nov 30 14:19:37 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Nov 2022 14:19:37 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v10]
In-Reply-To: <aPo22RBF75dw4FSOE8EgV4a3tOrMQoOKAoTzjW2-WQQ=.a654d873-0c04-43a8-8b97-c6243495028a@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <K0vkQwCONYUppMPTeeFg_v15LvT1_t8pvHVFQRtE2_g=.ee90fe13-2f26-4134-97c1-85f12fd7f79b@github.com>
 <8BUAotMUfrGALboIh4prz1m5D-K6_2891wwT1YAFcRc=.576207f8-74ff-435a-a193-efa51fa70553@github.com>
 <kkQ_QQyU9XhIyYAXSNR8fBiq5Mz0Vey7neGDxHTLNQk=.afc68a05-6492-4b83-9b6f-550a760a8c94@github.com>
 <FYy-PvEDYvz61PrqvzwxsMt4dy8N3IDXBpXxaHPX8uQ=.082466eb-6e61-45de-a176-b0c572a58163@github.com>
 <aPo22RBF75dw4FSOE8EgV4a3tOrMQoOKAoTzjW2-WQQ=.a654d873-0c04-43a8-8b97-c6243495028a@github.com>
Message-ID: <rYYzMVa-dQVpvDrJWJ2Rj2tBNahpu2kofM4rjierHi8=.e545767c-4a8c-423b-864d-4e8fdb184636@github.com>

On Wed, 30 Nov 2022 13:58:17 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> > What I meant in my earlier comment was the tests failed with the same errors/timeouts as previously. There was no InternalError thrown.
> 
> Thanks! No luck, then...

Would using the non-deprecated API be something worth investigating? In the meantime, I will try and find some more time to see if we can narrow down these failures on the systems where this is failing. I don't know how soon I can get to that.

-------------

PR: https://git.openjdk.org/jdk/pull/10140

From mcimadamore at openjdk.org  Wed Nov 30 15:14:26 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Nov 2022 15:14:26 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v34]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <HN_lq5U4JCG7wQCRjwb8qP9gYU-GWDgEEyBYpaNo33Y=.e93cc490-29eb-4ce0-af54-1b6f130d1ccf@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/5a75118b..ce85d182

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=32-33

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

PR: https://git.openjdk.org/jdk/pull/10872

From mcimadamore at openjdk.org  Wed Nov 30 15:30:40 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Nov 2022 15:30:40 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v35]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <qmTRPgpsuh3MB6RWmVW5G5Y46JWoevBnYC2ljqud5eY=.9571f7b3-113b-420d-90ec-f2f4207d3cc0@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

Maurizio Cimadamore 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 67 additional commits since the last revision:

 - Merge branch 'master' into PR_20
 - Address review comment
 - Polish javadoc:
   * Make sure that first para of class javadoc is succinct and descriptive
   * Remove references to "access" var handle or "memory segment view" var handle (just use var handle)
   * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para.
   * Other minor typos fixes
 - Address review comments
 - * remove unused Scoped interface
   * re-add trusting of final fields in layout class implementations
   * Fix BulkOps benchmark, which had alignment issues
 - Fix bit vs. byte mismatch in test
 - Fix wrong check in MemorySegment::spliterator/elements
   (The check which ensures that the segment size is multiple of spliterator element size is bogus)
 - Address more review comments
 - Fix bad @throws in MemorySegment::copy methods
 - Address review comments
 - ... and 57 more: https://git.openjdk.org/jdk/compare/d0d99ae1...8668fb39

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/ce85d182..8668fb39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=33-34

  Stats: 65983 lines in 1282 files changed: 30320 ins; 21180 del; 14483 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

PR: https://git.openjdk.org/jdk/pull/10872

From mkartashev at openjdk.org  Wed Nov 30 16:33:03 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 30 Nov 2022 16:33:03 GMT
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS) [v10]
In-Reply-To: <rYYzMVa-dQVpvDrJWJ2Rj2tBNahpu2kofM4rjierHi8=.e545767c-4a8c-423b-864d-4e8fdb184636@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <K0vkQwCONYUppMPTeeFg_v15LvT1_t8pvHVFQRtE2_g=.ee90fe13-2f26-4134-97c1-85f12fd7f79b@github.com>
 <8BUAotMUfrGALboIh4prz1m5D-K6_2891wwT1YAFcRc=.576207f8-74ff-435a-a193-efa51fa70553@github.com>
 <kkQ_QQyU9XhIyYAXSNR8fBiq5Mz0Vey7neGDxHTLNQk=.afc68a05-6492-4b83-9b6f-550a760a8c94@github.com>
 <FYy-PvEDYvz61PrqvzwxsMt4dy8N3IDXBpXxaHPX8uQ=.082466eb-6e61-45de-a176-b0c572a58163@github.com>
 <aPo22RBF75dw4FSOE8EgV4a3tOrMQoOKAoTzjW2-WQQ=.a654d873-0c04-43a8-8b97-c6243495028a@github.com>
 <rYYzMVa-dQVpvDrJWJ2Rj2tBNahpu2kofM4rjierHi8=.e545767c-4a8c-423b-864d-4e8fdb184636@github.com>
Message-ID: <JdoDnWORsJJYSjHxgihU84w8VirrRtOQjjmlfT9i1uw=.19e2f8e9-7cdd-4a6b-afb2-311b1fed0b86@github.com>

On Wed, 30 Nov 2022 14:16:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Would using the non-deprecated API be something worth investigating?

That's on my to-do list.

> In the meantime, I will try and find some more time to see if we can narrow down these failures on the systems where this is failing. I don't know how soon I can get to that.

Thanks anyway, much appreciated!

-------------

PR: https://git.openjdk.org/jdk/pull/10140

From alanb at openjdk.org  Wed Nov 30 16:41:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 16:41:16 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v35]
In-Reply-To: <qmTRPgpsuh3MB6RWmVW5G5Y46JWoevBnYC2ljqud5eY=.9571f7b3-113b-420d-90ec-f2f4207d3cc0@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <qmTRPgpsuh3MB6RWmVW5G5Y46JWoevBnYC2ljqud5eY=.9571f7b3-113b-420d-90ec-f2f4207d3cc0@github.com>
Message-ID: <ifYkXDEMXNqgWiktjDfPbS1dFLMkDosUfVrWCzzfobc=.d43429a8-82aa-4439-a6d9-60eafdc5c9b8@github.com>

On Wed, 30 Nov 2022 15:30:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore 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 67 additional commits since the last revision:
> 
>  - Merge branch 'master' into PR_20
>  - Address review comment
>  - Polish javadoc:
>    * Make sure that first para of class javadoc is succinct and descriptive
>    * Remove references to "access" var handle or "memory segment view" var handle (just use var handle)
>    * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para.
>    * Other minor typos fixes
>  - Address review comments
>  - * remove unused Scoped interface
>    * re-add trusting of final fields in layout class implementations
>    * Fix BulkOps benchmark, which had alignment issues
>  - Fix bit vs. byte mismatch in test
>  - Fix wrong check in MemorySegment::spliterator/elements
>    (The check which ensures that the segment size is multiple of spliterator element size is bogus)
>  - Address more review comments
>  - Fix bad @throws in MemorySegment::copy methods
>  - Address review comments
>  - ... and 57 more: https://git.openjdk.org/jdk/compare/4c9f206a...8668fb39

src/java.base/share/classes/java/nio/channels/FileChannel.java line 1004:

> 1002:      * Maps a region of this channel's file into a new mapped memory segment, with the given offset,
> 1003:      * size and memory session. The {@linkplain MemorySegment#address() address} of the returned memory segment
> 1004:      * is the starting address of the mapped off-heap region backing the segment.

Would you mind reflowing this paragraph to that the line lengths are a bit more consistent with the paragraphs that follow? That would also help with side-by-side views when looking at changes.

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From alanb at openjdk.org  Wed Nov 30 16:44:42 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 16:44:42 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v35]
In-Reply-To: <qmTRPgpsuh3MB6RWmVW5G5Y46JWoevBnYC2ljqud5eY=.9571f7b3-113b-420d-90ec-f2f4207d3cc0@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <qmTRPgpsuh3MB6RWmVW5G5Y46JWoevBnYC2ljqud5eY=.9571f7b3-113b-420d-90ec-f2f4207d3cc0@github.com>
Message-ID: <2wV4OEuvJQXQGnRNZ7qhv1PZuMlEYFBqnDgOp5L6D9U=.76a9f864-872a-4c39-a02e-2b0646414571@github.com>

On Wed, 30 Nov 2022 15:30:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore 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 67 additional commits since the last revision:
> 
>  - Merge branch 'master' into PR_20
>  - Address review comment
>  - Polish javadoc:
>    * Make sure that first para of class javadoc is succinct and descriptive
>    * Remove references to "access" var handle or "memory segment view" var handle (just use var handle)
>    * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para.
>    * Other minor typos fixes
>  - Address review comments
>  - * remove unused Scoped interface
>    * re-add trusting of final fields in layout class implementations
>    * Fix BulkOps benchmark, which had alignment issues
>  - Fix bit vs. byte mismatch in test
>  - Fix wrong check in MemorySegment::spliterator/elements
>    (The check which ensures that the segment size is multiple of spliterator element size is bogus)
>  - Address more review comments
>  - Fix bad @throws in MemorySegment::copy methods
>  - Address review comments
>  - ... and 57 more: https://git.openjdk.org/jdk/compare/e1da2b11...8668fb39

src/java.base/share/classes/java/lang/foreign/SegmentScope.java line 1:

> 1: package java.lang.foreign;

This one is missing a header.

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From alanb at openjdk.org  Wed Nov 30 16:49:00 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 16:49:00 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v35]
In-Reply-To: <qmTRPgpsuh3MB6RWmVW5G5Y46JWoevBnYC2ljqud5eY=.9571f7b3-113b-420d-90ec-f2f4207d3cc0@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <qmTRPgpsuh3MB6RWmVW5G5Y46JWoevBnYC2ljqud5eY=.9571f7b3-113b-420d-90ec-f2f4207d3cc0@github.com>
Message-ID: <1Ao-HvZlCHoGgLIJSJTXOOnvoR1pRtaZoljYUZpFEv0=.1a93bb09-06aa-4fad-905a-41f5f12b6945@github.com>

On Wed, 30 Nov 2022 15:30:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore 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 67 additional commits since the last revision:
> 
>  - Merge branch 'master' into PR_20
>  - Address review comment
>  - Polish javadoc:
>    * Make sure that first para of class javadoc is succinct and descriptive
>    * Remove references to "access" var handle or "memory segment view" var handle (just use var handle)
>    * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para.
>    * Other minor typos fixes
>  - Address review comments
>  - * remove unused Scoped interface
>    * re-add trusting of final fields in layout class implementations
>    * Fix BulkOps benchmark, which had alignment issues
>  - Fix bit vs. byte mismatch in test
>  - Fix wrong check in MemorySegment::spliterator/elements
>    (The check which ensures that the segment size is multiple of spliterator element size is bogus)
>  - Address more review comments
>  - Fix bad @throws in MemorySegment::copy methods
>  - Address review comments
>  - ... and 57 more: https://git.openjdk.org/jdk/compare/3e822e72...8668fb39

src/java.base/share/classes/java/lang/ModuleLayer.java line 313:

> 311:          * where possible.
> 312:          *
> 313:          * @since 20

We usually put the "@since 20" after the params/return/throws.

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From alanb at openjdk.org  Wed Nov 30 16:56:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 16:56:56 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v35]
In-Reply-To: <qmTRPgpsuh3MB6RWmVW5G5Y46JWoevBnYC2ljqud5eY=.9571f7b3-113b-420d-90ec-f2f4207d3cc0@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <qmTRPgpsuh3MB6RWmVW5G5Y46JWoevBnYC2ljqud5eY=.9571f7b3-113b-420d-90ec-f2f4207d3cc0@github.com>
Message-ID: <ba5_3zIynQPMBvz4RzI35uYxeHxfnH9fJYorRs6trvc=.f2fda441-74aa-4da7-bc7d-03e20a580b48@github.com>

On Wed, 30 Nov 2022 15:30:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore 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 67 additional commits since the last revision:
> 
>  - Merge branch 'master' into PR_20
>  - Address review comment
>  - Polish javadoc:
>    * Make sure that first para of class javadoc is succinct and descriptive
>    * Remove references to "access" var handle or "memory segment view" var handle (just use var handle)
>    * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para.
>    * Other minor typos fixes
>  - Address review comments
>  - * remove unused Scoped interface
>    * re-add trusting of final fields in layout class implementations
>    * Fix BulkOps benchmark, which had alignment issues
>  - Fix bit vs. byte mismatch in test
>  - Fix wrong check in MemorySegment::spliterator/elements
>    (The check which ensures that the segment size is multiple of spliterator element size is bogus)
>  - Address more review comments
>  - Fix bad @throws in MemorySegment::copy methods
>  - Address review comments
>  - ... and 57 more: https://git.openjdk.org/jdk/compare/9a07ecac...8668fb39

src/java.base/share/classes/java/lang/foreign/SegmentScope.java line 69:

> 67:      * Creates a new scope that is managed, automatically, by the garbage collector.
> 68:      * Segments associated with the returned scope can be
> 69:      * {@linkplain SegmentScope#isAccessibleBy(Thread) accessed} by multiple threads.

"can be accessed by multiple threads" hints a bit of concurrency. It might be clearer to say "by any thread".

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From alanb at openjdk.org  Wed Nov 30 17:08:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 17:08:13 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v35]
In-Reply-To: <qmTRPgpsuh3MB6RWmVW5G5Y46JWoevBnYC2ljqud5eY=.9571f7b3-113b-420d-90ec-f2f4207d3cc0@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <qmTRPgpsuh3MB6RWmVW5G5Y46JWoevBnYC2ljqud5eY=.9571f7b3-113b-420d-90ec-f2f4207d3cc0@github.com>
Message-ID: <9lmq8wD3c1YD4s0NGrHQXV6CgVJyJ9S42xUmx1FzXJ0=.2f64ed69-a54d-4517-ae29-1539f06cffe0@github.com>

On Wed, 30 Nov 2022 15:30:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore 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 67 additional commits since the last revision:
> 
>  - Merge branch 'master' into PR_20
>  - Address review comment
>  - Polish javadoc:
>    * Make sure that first para of class javadoc is succinct and descriptive
>    * Remove references to "access" var handle or "memory segment view" var handle (just use var handle)
>    * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para.
>    * Other minor typos fixes
>  - Address review comments
>  - * remove unused Scoped interface
>    * re-add trusting of final fields in layout class implementations
>    * Fix BulkOps benchmark, which had alignment issues
>  - Fix bit vs. byte mismatch in test
>  - Fix wrong check in MemorySegment::spliterator/elements
>    (The check which ensures that the segment size is multiple of spliterator element size is bogus)
>  - Address more review comments
>  - Fix bad @throws in MemorySegment::copy methods
>  - Address review comments
>  - ... and 57 more: https://git.openjdk.org/jdk/compare/ddc274f3...8668fb39

src/java.base/share/classes/java/lang/foreign/Arena.java line 135:

> 133:      * @apiNote This operation is not idempotent; that is, closing an already closed arena <em>always</em> results in an
> 134:      * exception being thrown. This reflects a deliberate design choice: arena state transitions should be
> 135:      * manifest in the client code; a failure in any of these transitions reveals a bug in the underlying application

Not important but I'm not sure about the wording here. Maybe you mean "manifested" or "should manifest" ?

src/java.base/share/classes/java/lang/foreign/Arena.java line 155:

> 153: 
> 154:     /**
> 155:      * {@return a new confined arena}

For completeness, this should probably say "a new confined arena owned by the current thread".

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From mik3hall at gmail.com  Wed Nov 30 17:09:09 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 30 Nov 2022 11:09:09 -0600
Subject: RFR: 8293067: (fs) Implement WatchService using system library
 (macOS)
In-Reply-To: <CAG0Tb0hKiWPpUtLWakWLoQhc-6aK6bHOoCr4AYLVR9h6gZ6KGg@mail.gmail.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com>
 <yHJ-B6sDutR1nM5-6X_XPm23QNecDCm8huOCKlV2CqQ=.d5916ff4-9ec9-4ab0-aaf9-992ce9dd485a@github.com>
 <oPER5lr5oJ3xEBP8FfBhp8UL3B_h4-m_PctelN3khOE=.e0ebb756-3d2f-44ac-ae36-aee9c898db7f@github.com>
 <9CB76C25-7A7E-4DE5-9E9B-ED28F244AFD2@gmail.com>
 <CAG0Tb0hKiWPpUtLWakWLoQhc-6aK6bHOoCr4AYLVR9h6gZ6KGg@mail.gmail.com>
Message-ID: <0D77CBEB-FEC0-4555-A970-77B829E7F779@gmail.com>



> On Nov 30, 2022, at 7:59 AM, Maxim Kartashev <maxim.kartashev at jetbrains.com> wrote:
> 
> FWIW I'm on 10.15
> 
> On Wed, Nov 30, 2022 at 4:31 PM Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
> 
> 
>> On Nov 13, 2022, at 9:31 AM, Alan Bateman <alanb at openjdk.org <mailto:alanb at openjdk.org>> wrote:
>> 
>> Unfortunately there is a lot of timeouts and intermittent failures and across quite a range of macOS releases (from 10.15 to 12.2).
> 
> Are there any errors after 12.2. I am 12.6. I am not sure what Maxim is. Is it possible it was an Apple issue that is fixed in recent releases?
> 

I guess we?re lucky or there?s something different about the failing infrastructure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221130/3d40ae2a/attachment.htm>

From pminborg at openjdk.org  Wed Nov 30 17:34:50 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Nov 2022 17:34:50 GMT
Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded
 [v17]
In-Reply-To: <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
References: <tzbeJwTDLtXbk0WxamhiKOy_sWY4iThA3Zs_tpf60mw=.ec2f2313-6303-4e58-9589-0fcf8f15b1ea@github.com>
 <DPeuhOVaS1QZMZw-vCpWcR0s16YNv2YrCV8IrUDtCas=.c02185b6-0f6e-4afa-bfe6-b92cf4ffc7f1@github.com>
Message-ID: <O_4QtLVtXPaRnaLB55n2OJvIrC7nVVtoomPKgGN8lpY=.e65580e4-a7ed-47b1-9e61-590646d0187d@github.com>

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. 
>> 
>> Design choices in this PR:
>> 
>> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems.
>> 
>> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~
>> 
>> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~
>> 
>> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own".
>> 
>> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not.
>> 
>> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove session exposure

I've converted this PR to a draft because we want to wait for the PR_20 branch being merged [JEP 434](https://openjdk.org/jeps/434)

-------------

PR: https://git.openjdk.org/jdk/pull/11260

From mcimadamore at openjdk.org  Wed Nov 30 18:14:00 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Nov 2022 18:14:00 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v36]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <1oR6S6K1w-GPz7Mw67Sqw9s8mPI4YDyC9_FOOjIqJU4=.9e645539-2bba-4740-be1e-e61493a3252f@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/8668fb39..df8a4a63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=34-35

  Stats: 34 lines in 3 files changed: 29 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

PR: https://git.openjdk.org/jdk/pull/10872

From alanb at openjdk.org  Wed Nov 30 20:35:29 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 20:35:29 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v36]
In-Reply-To: <1oR6S6K1w-GPz7Mw67Sqw9s8mPI4YDyC9_FOOjIqJU4=.9e645539-2bba-4740-be1e-e61493a3252f@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <1oR6S6K1w-GPz7Mw67Sqw9s8mPI4YDyC9_FOOjIqJU4=.9e645539-2bba-4740-be1e-e61493a3252f@github.com>
Message-ID: <B07OEJseK_eBEE-1qP-FJ3DnhV6Hxl3AfGQN4MH3Lwc=.17eee93d-41ec-4b9c-85af-74d2cfb3a5b6@github.com>

On Wed, 30 Nov 2022 18:14:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From mcimadamore at openjdk.org  Wed Nov 30 21:56:51 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Nov 2022 21:56:51 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v37]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <60l3vr69yRpaCUeht5gNEVsf7ODpvdqFHpHdjxnfkAo=.a9b6e1de-4f38-4cf2-a840-e5cb249c522c@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/df8a4a63..198f30c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=35-36

  Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

PR: https://git.openjdk.org/jdk/pull/10872

From mcimadamore at openjdk.org  Wed Nov 30 22:05:59 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Nov 2022 22:05:59 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v38]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <LmkFmp9yW9kSwMNUvERYQo7aI3C_PSeXoU0I7Yq-Pu4=.1e126451-43e7-43f0-938d-401ce907b7cc@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:

 - Merge branch 'master' into PR_20
 - Address review comments
 - Address review comments
 - Merge branch 'master' into PR_20
 - Address review comment
 - Polish javadoc:
   * Make sure that first para of class javadoc is succinct and descriptive
   * Remove references to "access" var handle or "memory segment view" var handle (just use var handle)
   * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para.
   * Other minor typos fixes
 - Address review comments
 - * remove unused Scoped interface
   * re-add trusting of final fields in layout class implementations
   * Fix BulkOps benchmark, which had alignment issues
 - Fix bit vs. byte mismatch in test
 - Fix wrong check in MemorySegment::spliterator/elements
   (The check which ensures that the segment size is multiple of spliterator element size is bogus)
 - ... and 60 more: https://git.openjdk.org/jdk/compare/4485d4e5...8b5dc0f0

-------------

Changes: https://git.openjdk.org/jdk/pull/10872/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=37
  Stats: 13807 lines in 254 files changed: 5780 ins; 4448 del; 3579 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

PR: https://git.openjdk.org/jdk/pull/10872