From github.com+471021+marschall at openjdk.java.net Sat May 1 13:21:50 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sat, 1 May 2021 13:21:50 GMT Subject: RFR: 8266320: (bf) ReadOnlyBufferException in heap buffer put(String, int, int) should not be conditional In-Reply-To: References: Message-ID: <07ApfrNgayYtrYCmIM7pAiKFIjiAJaRvMUR7amdn61M=.8d64bf86-89b7-4195-8fdb-e3d3ffec25eb@github.com> On Fri, 30 Apr 2021 15:25:40 GMT, Alan Bateman wrote: > would expect this case to be covered by an existing test already. Upon closer inspection this line seems to cover it already. It also establishes the existing behavior to be throwing `ReadOnlyBufferException` and not `BufferOverflowException`. Should I undo the added test in `Basic-X.java.template` and not add the bug id to `Basic.java`? https://github.com/openjdk/jdk/blob/5c083e8560ce9cc78615e3149a558206724cff53/test/jdk/java/nio/Buffer/Basic-X.java.template#L1003 ------------- PR: https://git.openjdk.java.net/jdk/pull/3809 From github.com+471021+marschall at openjdk.java.net Sat May 1 15:10:21 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sat, 1 May 2021 15:10:21 GMT Subject: RFR: 8266320: (bf) ReadOnlyBufferException in heap buffer put(String, int, int) should not be conditional [v2] In-Reply-To: References: Message-ID: <-UH6uHFZnRgdqa6R2SJkGEnjkVvHR81etr745MIbc-E=.034b4405-7792-4956-9213-980046df5a5a@github.com> > 8266320: (bf) ReadOnlyBufferException in heap buffer put(String,int,int) should not be conditional Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3809/files - new: https://git.openjdk.java.net/jdk/pull/3809/files/dd7177b4..43e74a89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3809&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3809&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3809.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3809/head:pull/3809 PR: https://git.openjdk.java.net/jdk/pull/3809 From alanb at openjdk.java.net Sat May 1 16:39:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 1 May 2021 16:39:51 GMT Subject: RFR: 8266320: (bf) ReadOnlyBufferException in heap buffer put(String, int, int) should not be conditional [v2] In-Reply-To: <07ApfrNgayYtrYCmIM7pAiKFIjiAJaRvMUR7amdn61M=.8d64bf86-89b7-4195-8fdb-e3d3ffec25eb@github.com> References: <07ApfrNgayYtrYCmIM7pAiKFIjiAJaRvMUR7amdn61M=.8d64bf86-89b7-4195-8fdb-e3d3ffec25eb@github.com> Message-ID: On Sat, 1 May 2021 13:18:31 GMT, Philippe Marschall wrote: >> src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template line 289: >> >>> 287: #else[rw] >>> 288: throw new ReadOnlyBufferException(); >>> 289: #end[rw] >> >> I assume this isn't technically a bug in that it's unspecified which exception is thrown when the buffer is read-only and an index is out of range. The change is okay of course. It would be useful to run the tests without the addition to Basic-X.java.template as I would expect this case to be covered by an existing test already. > >> would expect this case to be covered by an existing test already. > > Upon closer inspection this line seems to cover it already. It also establishes the existing behavior to be throwing `ReadOnlyBufferException` and not `BufferOverflowException`. Should I undo the added test in `Basic-X.java.template` and not add the bug id to `Basic.java`? > > https://github.com/openjdk/jdk/blob/5c083e8560ce9cc78615e3149a558206724cff53/test/jdk/java/nio/Buffer/Basic-X.java.template#L1003 Yes, I expected it was tested already so I think you can drop the change to Basic-X.java.template from the patch. That leaves the change to throw ReadOnlyBufferException unconditionally. As I said, if someone were to invoke this method on a read-only CharBuffer and with an out of range start or end index then ReadOnlyBufferException or IndexOutOfBoundsException are applicable. Existing behavior is to throw IOOBE. It's possible, but probably unlikely, that the behavior change will be observed by someone. A Release Note could be helpful. ------------- PR: https://git.openjdk.java.net/jdk/pull/3809 From github.com+471021+marschall at openjdk.java.net Sun May 2 13:43:11 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sun, 2 May 2021 13:43:11 GMT Subject: RFR: 8266320: (bf) ReadOnlyBufferException in heap buffer put(String, int, int) should not be conditional [v3] In-Reply-To: References: Message-ID: > 8266320: (bf) ReadOnlyBufferException in heap buffer put(String,int,int) should not be conditional Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision: Undo changes to tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3809/files - new: https://git.openjdk.java.net/jdk/pull/3809/files/43e74a89..150b0243 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3809&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3809&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3809.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3809/head:pull/3809 PR: https://git.openjdk.java.net/jdk/pull/3809 From alanb at openjdk.java.net Mon May 3 10:55:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 3 May 2021 10:55:51 GMT Subject: RFR: 8266320: (bf) ReadOnlyBufferException in heap buffer put(String, int, int) should not be conditional [v3] In-Reply-To: References: Message-ID: On Sun, 2 May 2021 13:43:11 GMT, Philippe Marschall wrote: >> 8266320: (bf) ReadOnlyBufferException in heap buffer put(String,int,int) should not be conditional > > Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision: > > Undo changes to tests Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3809 From bpb at openjdk.java.net Mon May 3 17:31:50 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 3 May 2021 17:31:50 GMT Subject: RFR: 8266320: (bf) ReadOnlyBufferException in heap buffer put(String, int, int) should not be conditional [v3] In-Reply-To: References: Message-ID: <8HNgiQIOFfYIE14maSv7F1IyzupAUbeQmoTHhe2JsTE=.e7af2e3d-937c-4aff-b698-bb467a1629b4@github.com> On Sun, 2 May 2021 13:43:11 GMT, Philippe Marschall wrote: >> 8266320: (bf) ReadOnlyBufferException in heap buffer put(String,int,int) should not be conditional > > Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision: > > Undo changes to tests Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3809 From bpb at openjdk.java.net Mon May 3 17:31:51 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 3 May 2021 17:31:51 GMT Subject: RFR: 8266320: (bf) ReadOnlyBufferException in heap buffer put(String, int, int) should not be conditional [v3] In-Reply-To: References: <07ApfrNgayYtrYCmIM7pAiKFIjiAJaRvMUR7amdn61M=.8d64bf86-89b7-4195-8fdb-e3d3ffec25eb@github.com> Message-ID: On Sat, 1 May 2021 16:36:48 GMT, Alan Bateman wrote: >>> would expect this case to be covered by an existing test already. >> >> Upon closer inspection this line seems to cover it already. It also establishes the existing behavior to be throwing `ReadOnlyBufferException` and not `BufferOverflowException`. Should I undo the added test in `Basic-X.java.template` and not add the bug id to `Basic.java`? >> >> https://github.com/openjdk/jdk/blob/5c083e8560ce9cc78615e3149a558206724cff53/test/jdk/java/nio/Buffer/Basic-X.java.template#L1003 > > Yes, I expected it was tested already so I think you can drop the change to Basic-X.java.template from the patch. > > That leaves the change to throw ReadOnlyBufferException unconditionally. As I said, if someone were to invoke this method on a read-only CharBuffer and with an out of range start or end index then ReadOnlyBufferException or IndexOutOfBoundsException are applicable. Existing behavior is to throw IOOBE. It's possible, but probably unlikely, that the behavior change will be observed by someone. A Release Note could be helpful. Probably order of checks with respect to read-only, IOOBEs, and over/underflow has changed in various places and needs to be reviewed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3809 From github.com+471021+marschall at openjdk.java.net Mon May 3 17:31:52 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Mon, 3 May 2021 17:31:52 GMT Subject: Integrated: 8266320: (bf) ReadOnlyBufferException in heap buffer put(String, int, int) should not be conditional In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 07:20:44 GMT, Philippe Marschall wrote: > 8266320: (bf) ReadOnlyBufferException in heap buffer put(String,int,int) should not be conditional This pull request has now been integrated. Changeset: 45760d4b Author: Philippe Marschall Committer: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/45760d4baf5da7537e1bae70796e869309d4aeff Stats: 7 lines in 1 file changed: 4 ins; 2 del; 1 mod 8266320: (bf) ReadOnlyBufferException in heap buffer put(String,int,int) should not be conditional Reviewed-by: alanb, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/3809 From vtewari at openjdk.java.net Tue May 4 04:36:49 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Tue, 4 May 2021 04:36:49 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Fri, 30 Apr 2021 14:04:46 GMT, Alan Bateman wrote: > This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. > > The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. > > I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). > > Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op > SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op > SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op > SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op > SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op > > > New wepoll based Selector: > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op > SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op > SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op > SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op > SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op > > > Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. > > CSR and Release Note planned. src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java line 111: > 109: try { > 110: begin(blocking); > 111: numEntries = WEPoll.wait(eph, pollArrayAddress, NUM_EPOLLEVENTS, (int) timeout); I think you meant to use 'to' in place of '(int) timeout'. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From vtewari at openjdk.java.net Tue May 4 05:10:51 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Tue, 4 May 2021 05:10:51 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Fri, 30 Apr 2021 14:04:46 GMT, Alan Bateman wrote: > This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. > > The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. > > I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). > > Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op > SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op > SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op > SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op > SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op > > > New wepoll based Selector: > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op > SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op > SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op > SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op > SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op > > > Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. > > CSR and Release Note planned. src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java line 248: > 246: private void clearInterrupt() throws IOException { > 247: synchronized (interruptLock) { > 248: IOUtil.drain(fd0Val); the modified implementation of IOUtil.drain is not throwing the IOException. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From vtewari at openjdk.java.net Tue May 4 05:45:53 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Tue, 4 May 2021 05:45:53 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Fri, 30 Apr 2021 14:04:46 GMT, Alan Bateman wrote: > This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. > > The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. > > I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). > > Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op > SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op > SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op > SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op > SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op > > > New wepoll based Selector: > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op > SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op > SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op > SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op > SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op > > > Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. > > CSR and Release Note planned. src/java.base/windows/native/libnio/ch/WEPollNatives.c line 2: > 1: /* > 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. copyright should be 2021 ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Tue May 4 05:55:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 05:55:51 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: <0aOpE3-EF2hvGSHK61QNj7h8quAWv-VLK4KkOVd04Gc=.b2624d66-55e7-4ab0-a67f-9ee1a6d1d733@github.com> On Tue, 4 May 2021 04:34:04 GMT, Vyom Tewari wrote: >> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. >> >> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. >> >> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). >> >> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op >> SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op >> SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op >> SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op >> SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op >> >> >> New wepoll based Selector: >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op >> SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op >> SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op >> SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op >> SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op >> >> >> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. >> >> CSR and Release Note planned. > > src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java line 111: > >> 109: try { >> 110: begin(blocking); >> 111: numEntries = WEPoll.wait(eph, pollArrayAddress, NUM_EPOLLEVENTS, (int) timeout); > > I think you meant to use 'to' in place of '(int) timeout'. Yes, thanks, this crept it when re-basing the change for the main line. > src/java.base/windows/native/libnio/ch/WEPollNatives.c line 2: > >> 1: /* >> 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. > > copyright should be 2021 Not sure, it was created and initially committed in 2020 and has not changed since then. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From vtewari at openjdk.java.net Tue May 4 06:05:50 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Tue, 4 May 2021 06:05:50 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Fri, 30 Apr 2021 14:04:46 GMT, Alan Bateman wrote: > This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. > > The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. > > I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). > > Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op > SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op > SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op > SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op > SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op > > > New wepoll based Selector: > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op > SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op > SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op > SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op > SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op > > > Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. > > CSR and Release Note planned. src/java.base/windows/classes/sun/nio/ch/WEPoll.java line 91: > 89: */ > 90: static long getEvent(long address, int i) { > 91: return address + (SIZEOF_EPOLLEVENT*i); space issue (SIZEOF_EPOLLEVENT*i); ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Tue May 4 08:23:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 08:23:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 15:20:42 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - Revert bad change in benchmark copyright > - Do not apply optimized bound check if accessed offset/length do not fit in an `int` value Just to double, there is no way to enable native access for modules in module layers (other than the boot layer), right? src/java.base/share/classes/java/lang/Module.java line 115: > 113: > 114: // is this module a native module > 115: private volatile boolean enableNativeAccess = false; Can you drop "= false", it's not needed and I don't think we want a volatile-write here. Also the comment may date from a previous iteration as there isn't any concept of a "native module". src/java.base/share/classes/java/lang/System.java line 2346: > 2344: public boolean isEnableNativeAccess(Module m) { > 2345: return m.isEnableNativeAccess(); > 2346: } Can you move this up so they are with the other Module methods? src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34: > 32: import java.util.Set; > 33: > 34: public final class IllegalNativeAccessChecker { Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access. src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 47: > 45: private static IllegalNativeAccessChecker checker; > 46: > 47: static Collection enableNativeAccessModules() { I assume this can be changed to Iterable as you don't want anything outside of this class changing the collection. src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 889: > 887: } else { > 888: // silently skip. > 889: // warnUnknownModule(ENABLE_NATIVE_ACCESS, name); Maybe for later but the other options do emit a warning when unknown module is specified. If the decoding of this command line option is moved to ModuleBootstrap then most of this class will go away and you will be able to use warnUnknownModule. src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 113: > 111: if (!SharedSecrets.getJavaLangAccess().isEnableNativeAccess(module)) { > 112: String moduleName = module.isNamed()? module.getName() : "UNNAMED"; > 113: throw new IllegalCallerException("Illegal native access from module: " + moduleName); "UNNAMED" is a bit inconsistent with the other exception messages. Can you just use Module::toString here instead, meaning "Illegal native access from " + module ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 09:54:04 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 09:54:04 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 08:20:43 GMT, Alan Bateman wrote: > Just to double, there is no way to enable native access for modules in module layers (other than the boot layer), right? No, at the moment it is not possible to enable native access programmatically. We will explore something along those lines in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 10:06:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 10:06:25 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v8] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Remove redundant initializer in Module - Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/793ea5c5..6a659d87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=06-07 Stats: 19 lines in 3 files changed: 6 ins; 11 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 11:58:22 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 11:58:22 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v9] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: - Tweak code some more - Use uniform naming convention for implementation metods in Module - Remove IllegalNativeAccessChecker ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/6a659d87..ead71078 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=07-08 Stats: 169 lines in 5 files changed: 41 ins; 114 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 12:05:16 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 12:05:16 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: References: Message-ID: <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com> On Tue, 4 May 2021 08:12:23 GMT, Alan Bateman wrote: >> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert bad change in benchmark copyright >> - Do not apply optimized bound check if accessed offset/length do not fit in an `int` value > > src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34: > >> 32: import java.util.Set; >> 33: >> 34: public final class IllegalNativeAccessChecker { > > Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access. I've decided to drop this class and move the logic in ModuleBootstrap. To handle unnamed modules, I had to piggy back on the special static ALL_UNNAMED module and set the flag there when decoding the command line option. This seems to be consistent with what is done in other areas. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 12:05:15 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 12:05:15 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v10] In-Reply-To: References: Message-ID: <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com> > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak comment in Module::enableNativeAccess ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/ead71078..2a31da40 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From jzaugg at openjdk.java.net Tue May 4 13:15:04 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Tue, 4 May 2021 13:15:04 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem Message-ID: If the given Path represents a file, use the overload of read defined in FileChannel that accepts an explicit position and avoid serializing reads. Note: The underlying NIO implementation is not required to implement FileChannel.read(ByteBuffer, long) concurrently; Windows still appears to lock, as it returns true for NativeDispatcher.needsPositionLock. On MacOS X, the enclosed benchmark improves from: Benchmark Mode Cnt Score Error Units ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op To: Benchmark Mode Cnt Score Error Units ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op ------------- Commit messages: - 8265448: Avoid lock contention in reads from zipfs when possible Changes: https://git.openjdk.java.net/jdk/pull/3853/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265448 Stats: 101 lines in 2 files changed: 97 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3853/head:pull/3853 PR: https://git.openjdk.java.net/jdk/pull/3853 From alanb at openjdk.java.net Tue May 4 14:13:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 14:13:51 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem In-Reply-To: References: Message-ID: On Tue, 4 May 2021 13:07:34 GMT, Jason Zaugg wrote: > If the given Path represents a file, use the overload of read defined > in FileChannel that accepts an explicit position and avoid serializing > reads. > > Note: The underlying NIO implementation is not required to implement > FileChannel.read(ByteBuffer, long) concurrently; Windows still appears > to lock, as it returns true for NativeDispatcher.needsPositionLock. > > > On MacOS X, the enclosed benchmark improves from: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op > > > To: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2223: > 2221: synchronized (zfch) { > 2222: n = zfch.position(pos).read(bb); > 2223: } @LanceAndersen Are you planning to look at this? Do you mind checking the async close case to make sure that the synchronization isn't masking anything? Also just to point out that pattern matching for instanceof ca be used here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From alanb at openjdk.java.net Tue May 4 14:24:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 14:24:56 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v10] In-Reply-To: <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com> References: <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com> Message-ID: On Tue, 4 May 2021 12:05:15 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tweak comment in Module::enableNativeAccess src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 112: > 110: Module module = currentClass.getModule(); > 111: if (!SharedSecrets.getJavaLangAccess().isEnableNativeAccess(module)) { > 112: throw new IllegalCallerException("Illegal native access from module: " + module); You may want to drop "module" from the exception message as Module::toString is specified to return "module XXXX" or "unnamed module XXXX" so you'll end up duplication "module" in the message. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From alanb at openjdk.java.net Tue May 4 14:24:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 14:24:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com> References: <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com> Message-ID: On Tue, 4 May 2021 12:01:44 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34: >> >>> 32: import java.util.Set; >>> 33: >>> 34: public final class IllegalNativeAccessChecker { >> >> Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access. > > I've decided to drop this class and move the logic in ModuleBootstrap. To handle unnamed modules, I had to piggy back on the special static ALL_UNNAMED module and set the flag there when decoding the command line option. This seems to be consistent with what is done in other areas. Good, this looks much simpler now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 14:37:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 14:37:25 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v11] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix message string in Reflection::ensureNativeAccess ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/2a31da40..72eb9bbc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From jzaugg at openjdk.java.net Tue May 4 22:24:20 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Tue, 4 May 2021 22:24:20 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v2] In-Reply-To: References: Message-ID: > If the given Path represents a file, use the overload of read defined > in FileChannel that accepts an explicit position and avoid serializing > reads. > > Note: The underlying NIO implementation is not required to implement > FileChannel.read(ByteBuffer, long) concurrently; Windows still appears > to lock, as it returns true for NativeDispatcher.needsPositionLock. > > > On MacOS X, the enclosed benchmark improves from: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op > > > To: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: Use pattern matching instanceof ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3853/files - new: https://git.openjdk.java.net/jdk/pull/3853/files/b7b6f9a8..0859d2d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3853/head:pull/3853 PR: https://git.openjdk.java.net/jdk/pull/3853 From alanb at openjdk.java.net Wed May 5 07:09:16 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 07:09:16 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v2] In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: > This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. > > The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. > > I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). > > Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op > SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op > SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op > SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op > SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op > > > New wepoll based Selector: > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op > SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op > SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op > SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op > SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op > > > Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. > > CSR and Release Note planned. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge - Propagate exception from discardOOB, cleanup - Merge - Use 'to' instead of '(int) timeout - Move SelectorWakeup micro to channels directory - Initial commit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3816/files - new: https://git.openjdk.java.net/jdk/pull/3816/files/82383674..50ea54c3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=00-01 Stats: 16301 lines in 294 files changed: 8226 ins; 4124 del; 3951 mod Patch: https://git.openjdk.java.net/jdk/pull/3816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3816/head:pull/3816 PR: https://git.openjdk.java.net/jdk/pull/3816 From michaelm at openjdk.java.net Wed May 5 08:17:05 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 5 May 2021 08:17:05 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v2] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Wed, 5 May 2021 07:09:16 GMT, Alan Bateman wrote: >> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. >> >> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. >> >> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). >> >> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op >> SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op >> SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op >> SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op >> SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op >> >> >> New wepoll based Selector: >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op >> SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op >> SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op >> SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op >> SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op >> >> >> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. >> >> CSR and Release Note planned. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge > - Propagate exception from discardOOB, cleanup > - Merge > - Use 'to' instead of '(int) timeout > - Move SelectorWakeup micro to channels directory > - Initial commit src/java.base/windows/native/libnio/ch/IOUtil.c line 155: > 153: { > 154: char buf[16]; > 155: jboolean readBytes = JNI_FALSE; Just curious why the drain buffer is 16 bytes now as opposed to 128 previously? ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Wed May 5 08:28:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 08:28:51 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v2] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Wed, 5 May 2021 07:45:14 GMT, Michael McMahon wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge >> - Propagate exception from discardOOB, cleanup >> - Merge >> - Use 'to' instead of '(int) timeout >> - Move SelectorWakeup micro to channels directory >> - Initial commit > > src/java.base/windows/native/libnio/ch/IOUtil.c line 155: > >> 153: { >> 154: char buf[16]; >> 155: jboolean readBytes = JNI_FALSE; > > Just curious why the drain buffer is 16 bytes now as opposed to 128 previously? It's only used by the wakeup mechanism so there should only be one byte to drain. So doesn't really matter, except that we don't want it too big as it allocated on the stack. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From michaelm at openjdk.java.net Wed May 5 09:39:57 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 5 May 2021 09:39:57 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v2] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Wed, 5 May 2021 07:09:16 GMT, Alan Bateman wrote: >> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. >> >> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. >> >> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). >> >> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op >> SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op >> SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op >> SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op >> SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op >> >> >> New wepoll based Selector: >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op >> SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op >> SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op >> SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op >> SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op >> >> >> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. >> >> CSR and Release Note planned. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge > - Propagate exception from discardOOB, cleanup > - Merge > - Use 'to' instead of '(int) timeout > - Move SelectorWakeup micro to channels directory > - Initial commit src/java.base/windows/classes/sun/nio/ch/WEPoll.java line 57: > 55: private static final int OFFSETOF_EVENTS = eventsOffset(); > 56: private static final int OFFSETOF_FD = dataOffset(); > 57: The naming here seems a bit inconsistent. The field in the union is called 'sock' but the constant value here refers to OFFSETOF_FD. Would OFFSETOF_SOCK be better? Also, is the getDescriptor() method needed as it doesn't seem to be called? What drew my attention to it is that 'fd' is an int size, but socket handles are long sized (which is how they are accessed through `getSocket` ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From chegar at openjdk.java.net Wed May 5 09:43:58 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 5 May 2021 09:43:58 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v2] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Wed, 5 May 2021 07:09:16 GMT, Alan Bateman wrote: >> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. >> >> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. >> >> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). >> >> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op >> SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op >> SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op >> SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op >> SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op >> >> >> New wepoll based Selector: >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op >> SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op >> SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op >> SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op >> SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op >> >> >> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. >> >> CSR and Release Note planned. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge > - Propagate exception from discardOOB, cleanup > - Merge > - Use 'to' instead of '(int) timeout > - Move SelectorWakeup micro to channels directory > - Initial commit src/java.base/share/classes/sun/nio/ch/Net.java line 685: > 683: * Read and discard urgent data (MSG_OOB) on the socket. > 684: */ > 685: static native boolean discardOOB(FileDescriptor fd) throws IOException; I see a native implementation of this method on Windows only, but it is in the shared `Net` class. This method is not called on non-Windows, but it it were there would be a problems ;-). Was the intention to add other platform specific implementations, or to confine it to Windows only? test/jdk/java/nio/channels/Selector/RacyDeregister.java line 47: > 45: * @run main/othervm/timeout=1200 -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider RacyDeregister > 46: */ > 47: I like how this test can be run with the system property set for Windows only - nice! test/micro/org/openjdk/bench/java/nio/channels/SelectOne.java line 80: > 78: ServerSocketChannel listener = ServerSocketChannel.open(); > 79: listener.bind(new InetSocketAddress(0)); > 80: SocketAddress remote = listener.getLocalAddress(); Maybe use a try-with-resources here so that the listener is closed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Wed May 5 09:48:17 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 09:48:17 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v3] In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: > This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. > > The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. > > I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). > > Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op > SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op > SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op > SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op > SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op > > > New wepoll based Selector: > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op > SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op > SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op > SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op > SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op > > > Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. > > CSR and Release Note planned. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Fix copyright header on SelectOne benchmark ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3816/files - new: https://git.openjdk.java.net/jdk/pull/3816/files/50ea54c3..8c9551a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=01-02 Stats: 28 lines in 1 file changed: 4 ins; 12 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/3816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3816/head:pull/3816 PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Wed May 5 10:01:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 10:01:51 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v2] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: <3_1Uu3f96_9j8b939Gto-MiKQRMW3308MUgdnYIPNVI=.391ffcf8-ce65-449a-a79b-b823b1f46066@github.com> On Wed, 5 May 2021 09:40:23 GMT, Chris Hegarty wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge >> - Propagate exception from discardOOB, cleanup >> - Merge >> - Use 'to' instead of '(int) timeout >> - Move SelectorWakeup micro to channels directory >> - Initial commit > > src/java.base/share/classes/sun/nio/ch/Net.java line 685: > >> 683: * Read and discard urgent data (MSG_OOB) on the socket. >> 684: */ >> 685: static native boolean discardOOB(FileDescriptor fd) throws IOException; > > I see a native implementation of this method on Windows only, but it is in the shared `Net` class. This method is not called on non-Windows, but it it were there would be a problems ;-). Was the intention to add other platform specific implementations, or to confine it to Windows only? It often happens in this area that Net and IOUtil define methods that aren't implemented on all platforms. In this case, discardOOB is generally useful and we can add it on other platforms when needed. I didn't add it now because it would not be used or tested. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Wed May 5 10:01:54 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 10:01:54 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v2] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Wed, 5 May 2021 09:33:51 GMT, Michael McMahon wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge >> - Propagate exception from discardOOB, cleanup >> - Merge >> - Use 'to' instead of '(int) timeout >> - Move SelectorWakeup micro to channels directory >> - Initial commit > > src/java.base/windows/classes/sun/nio/ch/WEPoll.java line 57: > >> 55: private static final int OFFSETOF_EVENTS = eventsOffset(); >> 56: private static final int OFFSETOF_FD = dataOffset(); >> 57: > > The naming here seems a bit inconsistent. The field in the union is called 'sock' but the constant value here refers to OFFSETOF_FD. Would OFFSETOF_SOCK be better? Also, is the getDescriptor() method needed as it doesn't seem to be called? What drew my attention to it is that 'fd' is an int size, but socket handles are long sized (which is how they are accessed through `getSocket` It's a union and they have the same offset. But okay, there may not be a need to provide access to data.fd, in which case getDescriptor could be removed and the private field renamed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Wed May 5 12:08:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 12:08:14 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v4] In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: > This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. > > The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. > > I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). > > Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op > SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op > SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op > SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op > SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op > > > New wepoll based Selector: > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op > SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op > SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op > SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op > SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op > > > Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. > > CSR and Release Note planned. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Remove unused WEPoll.getDescriptor. Update micro to close listener ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3816/files - new: https://git.openjdk.java.net/jdk/pull/3816/files/8c9551a5..8103c0ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=02-03 Stats: 24 lines in 2 files changed: 1 ins; 7 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3816/head:pull/3816 PR: https://git.openjdk.java.net/jdk/pull/3816 From dfuchs at openjdk.java.net Wed May 5 12:13:55 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 5 May 2021 12:13:55 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v3] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Wed, 5 May 2021 09:48:17 GMT, Alan Bateman wrote: >> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. >> >> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. >> >> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). >> >> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op >> SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op >> SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op >> SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op >> SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op >> >> >> New wepoll based Selector: >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op >> SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op >> SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op >> SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op >> SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op >> >> >> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. >> >> CSR and Release Note planned. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright header on SelectOne benchmark src/java.base/windows/native/libnio/ch/Net.c line 791: > 789: JNIEXPORT jboolean JNICALL > 790: Java_sun_nio_ch_Net_discardOOB(JNIEnv* env, jclass clazz, jobject fdo) > 791: { This seems surprisingly close to the logic of the drain method above (IOUtil.c). Would it make sense to factorize some of it? ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Wed May 5 12:21:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 12:21:56 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v3] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: <-FGEagc4l-G9yREQrbbRP4uK3wOn_UHuzg1K56XSkcY=.b7a0f047-2af4-440c-a070-fbf555ed7a90@github.com> On Wed, 5 May 2021 12:00:12 GMT, Daniel Fuchs wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright header on SelectOne benchmark > > src/java.base/windows/native/libnio/ch/Net.c line 791: > >> 789: JNIEXPORT jboolean JNICALL >> 790: Java_sun_nio_ch_Net_discardOOB(JNIEnv* env, jclass clazz, jobject fdo) >> 791: { > > This seems surprisingly close to the logic of the drain method above (IOUtil.c). Would it make sense to factorize some of it? For now, this method sits sendOOB. There is some historical/legacy debt in this area in that some methods for network sockets have been added to IOUtil instead of Net. I do plan to re-visit this at some point but I'd prefer not do it in this PR because it requires touching all the Selector implementations. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From pconcannon at openjdk.java.net Wed May 5 14:44:59 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 5 May 2021 14:44:59 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v4] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: <5LWNu412K6bCxNU69M_FGC3X7tn4etcxrGsIc_2s-Bo=.e3078248-3a84-4e37-b17c-5852a62d3445@github.com> On Wed, 5 May 2021 12:08:14 GMT, Alan Bateman wrote: >> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. >> >> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. >> >> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). >> >> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op >> SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op >> SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op >> SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op >> SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op >> >> >> New wepoll based Selector: >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op >> SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op >> SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op >> SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op >> SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op >> >> >> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. >> >> CSR and Release Note planned. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused WEPoll.getDescriptor. Update micro to close listener src/java.base/windows/native/libnio/ch/WEPollNatives.c line 56: > 54: Java_sun_nio_ch_WEPoll_create(JNIEnv *env, jclass clazz) { > 55: HANDLE h = epoll_create1(0); > 56: if (h < 0) { Just wondering should you be checking for `NULL` here instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Wed May 5 14:47:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 14:47:51 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v4] In-Reply-To: <5LWNu412K6bCxNU69M_FGC3X7tn4etcxrGsIc_2s-Bo=.e3078248-3a84-4e37-b17c-5852a62d3445@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> <5LWNu412K6bCxNU69M_FGC3X7tn4etcxrGsIc_2s-Bo=.e3078248-3a84-4e37-b17c-5852a62d3445@github.com> Message-ID: <0njIETUX6OU5rJhGt4U1cVrOJl4hMM2IOfeAGTjc6yw=.a2369934-2054-4e4c-a82a-a75f39e00231@github.com> On Wed, 5 May 2021 14:42:25 GMT, Patrick Concannon wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused WEPoll.getDescriptor. Update micro to close listener > > src/java.base/windows/native/libnio/ch/WEPollNatives.c line 56: > >> 54: Java_sun_nio_ch_WEPoll_create(JNIEnv *env, jclass clazz) { >> 55: HANDLE h = epoll_create1(0); >> 56: if (h < 0) { > > Just wondering should you be checking for `NULL` here instead? Well spotted, it should check for NULL (a subtle difference with regular epoll_create1). ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From chegar at openjdk.java.net Wed May 5 15:16:59 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 5 May 2021 15:16:59 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v2] In-Reply-To: <3_1Uu3f96_9j8b939Gto-MiKQRMW3308MUgdnYIPNVI=.391ffcf8-ce65-449a-a79b-b823b1f46066@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> <3_1Uu3f96_9j8b939Gto-MiKQRMW3308MUgdnYIPNVI=.391ffcf8-ce65-449a-a79b-b823b1f46066@github.com> Message-ID: On Wed, 5 May 2021 09:59:25 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/nio/ch/Net.java line 685: >> >>> 683: * Read and discard urgent data (MSG_OOB) on the socket. >>> 684: */ >>> 685: static native boolean discardOOB(FileDescriptor fd) throws IOException; >> >> I see a native implementation of this method on Windows only, but it is in the shared `Net` class. This method is not called on non-Windows, but it it were there would be a problems ;-). Was the intention to add other platform specific implementations, or to confine it to Windows only? > > It often happens in this area that Net and IOUtil define methods that aren't implemented on all platforms. In this case, discardOOB is generally useful and we can add it on other platforms when needed. I didn't add it now because it would not be used or tested. This attracted my attention because it is a new native method. I don't see any other native methods unimplemented here, but I only skimmed over the code. Seems very fragile, since it will (may) throw a linkage error if called on non-Windows platforms - without any help from the compiler, we are dependent on good tests to catch such. If this is an established pattern, then ok, but I would like to revisit it separately to this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Wed May 5 15:31:24 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 15:31:24 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v5] In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: > This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. > > The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. > > I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). > > Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op > SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op > SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op > SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op > SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op > > > New wepoll based Selector: > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op > SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op > SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op > SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op > SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op > > > Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. > > CSR and Release Note planned. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: epoll_create1 returns NULL on error ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3816/files - new: https://git.openjdk.java.net/jdk/pull/3816/files/8103c0ea..221af5a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3816/head:pull/3816 PR: https://git.openjdk.java.net/jdk/pull/3816 From chegar at openjdk.java.net Wed May 5 15:31:24 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 5 May 2021 15:31:24 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v4] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Wed, 5 May 2021 12:08:14 GMT, Alan Bateman wrote: >> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. >> >> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. >> >> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). >> >> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op >> SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op >> SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op >> SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op >> SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op >> >> >> New wepoll based Selector: >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op >> SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op >> SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op >> SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op >> SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op >> >> >> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. >> >> CSR and Release Note planned. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused WEPoll.getDescriptor. Update micro to close listener Overall, this looks like a very nice addition. src/java.base/windows/classes/sun/nio/ch/WEPoll.java line 78: > 76: static long allocatePollArray(int count) { > 77: return UNSAFE.allocateMemory(count * SIZEOF_EPOLLEVENT); > 78: } I expected to see the memory cleared here, e.g.: long base = UNSAFE.allocateMemory(count * SIZEOF_EPOLLEVENT); UNSAFE.setMemory(base, count * SIZEOF_EPOLLEVENT, (byte) 0); return base; ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Wed May 5 15:34:49 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 15:34:49 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v2] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> <3_1Uu3f96_9j8b939Gto-MiKQRMW3308MUgdnYIPNVI=.391ffcf8-ce65-449a-a79b-b823b1f46066@github.com> Message-ID: On Wed, 5 May 2021 15:14:14 GMT, Chris Hegarty wrote: >> It often happens in this area that Net and IOUtil define methods that aren't implemented on all platforms. In this case, discardOOB is generally useful and we can add it on other platforms when needed. I didn't add it now because it would not be used or tested. > > This attracted my attention because it is a new native method. I don't see any other native methods unimplemented here, but I only skimmed over the code. Seems very fragile, since it will (may) throw a linkage error if called on non-Windows platforms - without any help from the compiler, we are dependent on good tests to catch such. If this is an established pattern, then ok, but I would like to revisit it separately to this PR. IOUtil.makePipe is another example. It has been there since JDK 1.4 but doesn't have an implementation on Windows. The Net.localXXX methods didn't have implementations on all platforms for a long time too. So yes, if someone where to write some platform specific code in sun.nio.ch and use one of the unimplemented methods then it would be an error at runtime. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From lancea at openjdk.java.net Wed May 5 15:52:00 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 5 May 2021 15:52:00 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v2] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 14:10:52 GMT, Alan Bateman wrote: >> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: >> >> Use pattern matching instanceof > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2223: > >> 2221: synchronized (zfch) { >> 2222: n = zfch.position(pos).read(bb); >> 2223: } > > @LanceAndersen Are you planning to look at this? Do you mind checking the async close case to make sure that the synchronization isn't masking anything? > > Also just to point out that pattern matching for instanceof ca be used here. Yes, I plan to look at this. It would also be good to have a couple of additional reviews as well :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From alanb at openjdk.java.net Wed May 5 16:06:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 May 2021 16:06:53 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 15:49:00 GMT, Lance Andersen wrote: >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2223: >> >>> 2221: synchronized (zfch) { >>> 2222: n = zfch.position(pos).read(bb); >>> 2223: } >> >> @LanceAndersen Are you planning to look at this? Do you mind checking the async close case to make sure that the synchronization isn't masking anything? >> >> Also just to point out that pattern matching for instanceof ca be used here. > > Yes, I plan to look at this. It would also be good to have a couple of additional reviews as well :-) I think using the positional read on the underlying FileChannel is okay. I'm puzzled by the previous code as I would have expected it to restore the position (make me wonder if there are zipfs tests for this). ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From bpb at openjdk.java.net Wed May 5 20:59:12 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 5 May 2021 20:59:12 GMT Subject: RFR: 8266589: (fs) Improve performance of Files.copy() on macOS using copyfile(3) Message-ID: Please consider this request to use `fcopyfile(3)` to copy files via `java.nio.file.Files(Path,Path,CopyOption...)` on macOS. This change would improve the throughput of `Files.copy()` as shown in these results: **Copy via 8192 byte buffers** Benchmark (size) Mode Cnt Score Error Units FilesCopy.copy 10240 thrpt 5 5432.671 ? 137.114 ops/s FilesCopy.copy 51200 thrpt 5 3959.145 ? 157.467 ops/s FilesCopy.copy 102400 thrpt 5 2931.325 ? 109.200 ops/s FilesCopy.copy 512000 thrpt 5 655.550 ? 39.919 ops/s FilesCopy.copy 1048568 thrpt 5 375.127 ? 10.111 ops/s FilesCopy.copy 10485760 thrpt 5 64.048 ? 5.740 ops/s FilesCopy.copy 104857600 thrpt 5 6.893 ? 0.415 ops/s FilesCopy.copy 1073741824 thrpt 5 0.717 ? 0.026 ops/s **Copy via fcopyfile** Benchmark (size) Mode Cnt Score Error Units FilesCopy.copy 10240 thrpt 5 5070.255 ? 817.419 ops/s FilesCopy.copy 51200 thrpt 5 4469.218 ? 65.634 ops/s FilesCopy.copy 102400 thrpt 5 3997.718 ? 301.440 ops/s FilesCopy.copy 512000 thrpt 5 2064.223 ? 68.893 ops/s FilesCopy.copy 1048568 thrpt 5 817.743 ? 83.076 ops/s FilesCopy.copy 10485760 thrpt 5 145.799 ? 3.674 ops/s FilesCopy.copy 104857600 thrpt 5 24.706 ? 14.178 ops/s FilesCopy.copy 1073741824 thrpt 5 1.386 ? 0.073 ops/s The smallest size tested shows a small degradation in throughput, but this could be rectified if desired by adding an empirically determined size threshold under which user-space buffers would be used instead of `fcopyfile()`. A small change is also made to the Linux `sendfile()` portion to use the largest permitted `count` value if the copy is uninterruptible, i.e., `cancel == NULL`. ------------- Commit messages: - 8266589: (fs) Improve performance of Files.copy() on macOS using copyfile(3) Changes: https://git.openjdk.java.net/jdk/pull/3890/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3890&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266589 Stats: 38 lines in 1 file changed: 35 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3890.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3890/head:pull/3890 PR: https://git.openjdk.java.net/jdk/pull/3890 From jzaugg at openjdk.java.net Wed May 5 23:25:50 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Wed, 5 May 2021 23:25:50 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 16:03:17 GMT, Alan Bateman wrote: >> Yes, I plan to look at this. It would also be good to have a couple of additional reviews as well :-) > > I think using the positional read on the underlying FileChannel is okay. I'm puzzled by the previous code as I would have expected it to restore the position (make me wonder if there are zipfs tests for this). My reading of the existing code is that the only position-influenced method called on the channel (either via `ZipFileSystem.ch` or `ZipFileSystem$EntryInputStream.zfch`) is `read`, and this is only called in the `.position(pos).read(...)` idiom. The failure to reset the position doesn't affect correctness. However the `synchronzized` _is_ definitely needed to avoid races. Incidentally, regarding this comment: private class EntryInputStream extends InputStream { private final SeekableByteChannel zfch; // local ref to zipfs's "ch". zipfs.ch might // point to a new channel after sync() If the file system is writable and updated, the underlying file is deleted and replaced with a temporary file by `close()` / `sync()`, but `ZipFileSystem.ch` is itself final since d581e4f4. I believe the comment is outdated and `EntryInputStream` could just access ch via the outer pointer. That change would simplify this patch marginally. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From jzaugg at openjdk.java.net Wed May 5 23:40:21 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Wed, 5 May 2021 23:40:21 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v3] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 23:23:21 GMT, Jason Zaugg wrote: >> I think using the positional read on the underlying FileChannel is okay. I'm puzzled by the previous code as I would have expected it to restore the position (make me wonder if there are zipfs tests for this). > > My reading of the existing code is that the only position-influenced method called on the channel (either via `ZipFileSystem.ch` or `ZipFileSystem$EntryInputStream.zfch`) is `read`, and this is only called in the `.position(pos).read(...)` idiom. The failure to reset the position doesn't affect correctness. However the `synchronzized` _is_ definitely needed to avoid races. > > Incidentally, regarding this comment: > > private class EntryInputStream extends InputStream { > private final SeekableByteChannel zfch; // local ref to zipfs's "ch". zipfs.ch might > // point to a new channel after sync() > > If the file system is writable and updated, the underlying file is deleted and replaced with a temporary file by `close()` / `sync()`, but `ZipFileSystem.ch` is itself final since d581e4f4. I believe the comment is outdated and `EntryInputStream` could just access ch via the outer pointer. That change would simplify this patch marginally. I've added the simplifying commit for now, but I'm happy to split that to a separate change if you prefer. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From jzaugg at openjdk.java.net Wed May 5 23:40:20 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Wed, 5 May 2021 23:40:20 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v3] In-Reply-To: References: Message-ID: > If the given Path represents a file, use the overload of read defined > in FileChannel that accepts an explicit position and avoid serializing > reads. > > Note: The underlying NIO implementation is not required to implement > FileChannel.read(ByteBuffer, long) concurrently; Windows still appears > to lock, as it returns true for NativeDispatcher.needsPositionLock. > > > On MacOS X, the enclosed benchmark improves from: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op > > > To: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: Access ZipFileSystem.ch via outer pointer as it is now final ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3853/files - new: https://git.openjdk.java.net/jdk/pull/3853/files/0859d2d6..bccf5d3c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=01-02 Stats: 15 lines in 1 file changed: 0 ins; 11 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3853/head:pull/3853 PR: https://git.openjdk.java.net/jdk/pull/3853 From jzaugg at openjdk.java.net Thu May 6 00:03:20 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Thu, 6 May 2021 00:03:20 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v4] In-Reply-To: References: Message-ID: > If the given Path represents a file, use the overload of read defined > in FileChannel that accepts an explicit position and avoid serializing > reads. > > Note: The underlying NIO implementation is not required to implement > FileChannel.read(ByteBuffer, long) concurrently; Windows still appears > to lock, as it returns true for NativeDispatcher.needsPositionLock. > > > On MacOS X, the enclosed benchmark improves from: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op > > > To: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: Remove redundant cast from previous commit. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3853/files - new: https://git.openjdk.java.net/jdk/pull/3853/files/bccf5d3c..c9758c58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3853/head:pull/3853 PR: https://git.openjdk.java.net/jdk/pull/3853 From alanb at openjdk.java.net Thu May 6 07:43:54 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 May 2021 07:43:54 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v4] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 00:03:20 GMT, Jason Zaugg wrote: >> If the given Path represents a file, use the overload of read defined >> in FileChannel that accepts an explicit position and avoid serializing >> reads. >> >> Note: The underlying NIO implementation is not required to implement >> FileChannel.read(ByteBuffer, long) concurrently; Windows still appears >> to lock, as it returns true for NativeDispatcher.needsPositionLock. >> >> >> On MacOS X, the enclosed benchmark improves from: >> >> >> Benchmark Mode Cnt Score Error Units >> ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op >> >> >> To: >> >> >> Benchmark Mode Cnt Score Error Units >> ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op > > Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant cast from previous commit. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1235: > 1233: synchronized(ch) { > 1234: return ch.position(pos).read(bb); > 1235: } I think it's okay to include the update to EntryInputStream, that part looks fine, as does the directly use of the FileChannel positional read. I'm still mulling over the case where ch is not a FileChannel as I would expected it to capture the existing position and restore it after the read. I think this is the degenerative case when the zip file is located in a custom file system that doesn't support FileChannel. In that case, positional read has to be implemented on the most basic SeekableByteChannel. It would only be observed when mixing positional read ops with other ops that depend on the current position. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From jzaugg at openjdk.java.net Thu May 6 08:07:51 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Thu, 6 May 2021 08:07:51 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v4] In-Reply-To: References: Message-ID: <2yiP6HEx1W_6XobXJxeo_NuQjFROQpRVZZp8_RP1jrE=.9aa6c044-442e-4435-83b3-bd3f68c3c043@github.com> On Thu, 6 May 2021 07:41:00 GMT, Alan Bateman wrote: >> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove redundant cast from previous commit. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1235: > >> 1233: synchronized(ch) { >> 1234: return ch.position(pos).read(bb); >> 1235: } > > I think it's okay to include the update to EntryInputStream, that part looks fine, as does the directly use of the FileChannel positional read. > > I'm still mulling over the case where ch is not a FileChannel as I would expected it to capture the existing position and restore it after the read. I think this is the degenerative case when the zip file is located in a custom file system that doesn't support FileChannel. In that case, positional read has to be implemented on the most basic SeekableByteChannel. It would only be observed when mixing positional read ops with other ops that depend on the current position. Here are all the references to `ch`. this.ch = Files.newByteChannel(zfpath, READ); ... this.ch.close(); ... ch.close(); // close the ch just in case no update ... if (ch instanceof FileChannel fch) { return fch.read(bb, pos); } else { synchronized(ch) { return ch.position(pos).read(bb); } } ... long ziplen = ch.size(); ... ch.close(); It appears the only position-dependent operation called `read(ByteBuffer)`. This is performed together with the `pos` call within the `synchronized(ch)` lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From michaelm at openjdk.java.net Thu May 6 08:53:52 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 6 May 2021 08:53:52 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v5] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Wed, 5 May 2021 15:31:24 GMT, Alan Bateman wrote: >> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. >> >> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. >> >> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). >> >> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op >> SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op >> SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op >> SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op >> SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op >> >> >> New wepoll based Selector: >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op >> SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op >> SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op >> SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op >> SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op >> >> >> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. >> >> CSR and Release Note planned. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > epoll_create1 returns NULL on error Marked as reviewed by michaelm (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From vtewari at openjdk.java.net Thu May 6 09:31:59 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Thu, 6 May 2021 09:31:59 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v5] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: <6uy9GgikWS5nOywPALCmA-gkLsdFDWfAcXEEEO398VU=.1bfaf3cf-55c3-4f05-9f25-ab47168de1c9@github.com> On Wed, 5 May 2021 15:31:24 GMT, Alan Bateman wrote: >> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. >> >> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. >> >> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). >> >> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op >> SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op >> SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op >> SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op >> SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op >> >> >> New wepoll based Selector: >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op >> SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op >> SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op >> SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op >> SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op >> >> >> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. >> >> CSR and Release Note planned. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > epoll_create1 returns NULL on error LGTM ------------- Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.java.net/jdk/pull/3816 From yyang at openjdk.java.net Thu May 6 10:14:16 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 6 May 2021 10:14:16 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v7] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - cmp clobbers its left argument on x86_32 - Merge branch 'master' into consolidate_checkindex - better check1-4 - AssertionError when expected exception was not thrown - remove extra newline - remove InlineNIOCheckIndex flag - remove java_nio_Buffer in javaClasses.hpp - consolidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/3615/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=06 Stats: 331 lines in 11 files changed: 235 ins; 78 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From yyang at openjdk.java.net Thu May 6 11:17:18 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 6 May 2021 11:17:18 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v8] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: build failed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/e4959148..f996c99f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From alanb at openjdk.java.net Thu May 6 13:18:24 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 May 2021 13:18:24 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v6] In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: > This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. > > The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. > > I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). > > Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op > SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op > SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op > SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op > SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op > > > New wepoll based Selector: > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op > SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op > SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op > SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op > SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op > > > Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. > > CSR and Release Note planned. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge - Bring back getDescriptor, bzero poll array when initially created - epoll_create1 returns NULL on error - Remove unused WEPoll.getDescriptor. Update micro to close listener - Fix copyright header on SelectOne benchmark - Merge - Propagate exception from discardOOB, cleanup - Merge - Use 'to' instead of '(int) timeout - Move SelectorWakeup micro to channels directory - ... and 1 more: https://git.openjdk.java.net/jdk/compare/6788ff46...260b13fe ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3816/files - new: https://git.openjdk.java.net/jdk/pull/3816/files/221af5a6..260b13fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=04-05 Stats: 2470 lines in 111 files changed: 1674 ins; 638 del; 158 mod Patch: https://git.openjdk.java.net/jdk/pull/3816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3816/head:pull/3816 PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Thu May 6 13:21:58 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 May 2021 13:21:58 GMT Subject: RFR: 8266589: (fs) Improve performance of Files.copy() on macOS using copyfile(3) In-Reply-To: References: Message-ID: On Wed, 5 May 2021 20:51:59 GMT, Brian Burkhalter wrote: > Please consider this request to use `fcopyfile(3)` to copy files via `java.nio.file.Files(Path,Path,CopyOption...)` on macOS. This change would improve the throughput of `Files.copy()` as shown in these results: > > **Copy via 8192 byte buffers** > > > Benchmark (size) Mode Cnt Score Error Units > FilesCopy.copy 10240 thrpt 5 5432.671 ? 137.114 ops/s > FilesCopy.copy 51200 thrpt 5 3959.145 ? 157.467 ops/s > FilesCopy.copy 102400 thrpt 5 2931.325 ? 109.200 ops/s > FilesCopy.copy 512000 thrpt 5 655.550 ? 39.919 ops/s > FilesCopy.copy 1048568 thrpt 5 375.127 ? 10.111 ops/s > FilesCopy.copy 10485760 thrpt 5 64.048 ? 5.740 ops/s > FilesCopy.copy 104857600 thrpt 5 6.893 ? 0.415 ops/s > FilesCopy.copy 1073741824 thrpt 5 0.717 ? 0.026 ops/s > > > **Copy via fcopyfile** > > > Benchmark (size) Mode Cnt Score Error Units > FilesCopy.copy 10240 thrpt 5 5070.255 ? 817.419 ops/s > FilesCopy.copy 51200 thrpt 5 4469.218 ? 65.634 ops/s > FilesCopy.copy 102400 thrpt 5 3997.718 ? 301.440 ops/s > FilesCopy.copy 512000 thrpt 5 2064.223 ? 68.893 ops/s > FilesCopy.copy 1048568 thrpt 5 817.743 ? 83.076 ops/s > FilesCopy.copy 10485760 thrpt 5 145.799 ? 3.674 ops/s > FilesCopy.copy 104857600 thrpt 5 24.706 ? 14.178 ops/s > FilesCopy.copy 1073741824 thrpt 5 1.386 ? 0.073 ops/s > > > The smallest size tested shows a small degradation in throughput, but this could be rectified if desired by adding an empirically determined size threshold under which user-space buffers would be used instead of `fcopyfile()`. > > A small change is also made to the Linux `sendfile()` portion to use the largest permitted `count` value if the copy is uninterruptible, i.e., `cancel == NULL`. src/java.base/unix/native/libnio/fs/UnixCopyFile.c line 65: > 63: return COPYFILE_CONTINUE; > 64: } > 65: #endif I wasn't aware of this fcopyfile but it seems to be a good match. At some point I think we will have to split up UnixCopyFile to make it easier to maintain the different implementations. That might be the opportunity to do more than COPYFILE_DATA, meaning we could get it to copy the meta data too. I think we should try to re-format the callback a bit to make it easier to distinguish the conditions in the if-statement from the body. I probably should re-format the declaration too to get it a more more consistent/readable. ------------- PR: https://git.openjdk.java.net/jdk/pull/3890 From alanb at openjdk.java.net Thu May 6 13:27:58 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 May 2021 13:27:58 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v4] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Wed, 5 May 2021 15:25:55 GMT, Chris Hegarty wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused WEPoll.getDescriptor. Update micro to close listener > > src/java.base/windows/classes/sun/nio/ch/WEPoll.java line 78: > >> 76: static long allocatePollArray(int count) { >> 77: return UNSAFE.allocateMemory(count * SIZEOF_EPOLLEVENT); >> 78: } > > I expected to see the memory cleared here, e.g.: > > long base = UNSAFE.allocateMemory(count * SIZEOF_EPOLLEVENT); > UNSAFE.setMemory(base, count * SIZEOF_EPOLLEVENT, (byte) 0); > return base; Okay, will do, although isn't really needed here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From mcimadamore at openjdk.java.net Thu May 6 14:23:27 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 6 May 2021 14:23:27 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v12] In-Reply-To: References: Message-ID: <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com> > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/72eb9bbc..926229ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=10-11 Stats: 45 lines in 8 files changed: 0 ins; 0 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From dfuchs at openjdk.java.net Thu May 6 15:54:57 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 6 May 2021 15:54:57 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v6] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Thu, 6 May 2021 13:18:24 GMT, Alan Bateman wrote: >> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. >> >> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. >> >> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). >> >> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op >> SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op >> SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op >> SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op >> SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op >> >> >> New wepoll based Selector: >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op >> SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op >> SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op >> SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op >> SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op >> >> >> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. >> >> CSR and Release Note planned. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge > - Bring back getDescriptor, bzero poll array when initially created > - epoll_create1 returns NULL on error > - Remove unused WEPoll.getDescriptor. Update micro to close listener > - Fix copyright header on SelectOne benchmark > - Merge > - Propagate exception from discardOOB, cleanup > - Merge > - Use 'to' instead of '(int) timeout > - Move SelectorWakeup micro to channels directory > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4e9b05eb...260b13fe test/micro/org/openjdk/bench/java/nio/channels/SelectOne.java line 71: > 69: > 70: try (ServerSocketChannel listener = ServerSocketChannel.open()) { > 71: listener.bind(new InetSocketAddress(0)); Is using the wildcard really necessary here? I am concerned that the test is relying on unspecified behaviour - namely: - listener is bound to the wildcard - listener.getLocalAddress() is *probably* the wildcard - later SocketChannel is connected using that address which is still *probably* the wildcard. For the sake of stability - should the test preferably use InetAddress.getLoopbackAddress() for binding and connecting? ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Thu May 6 16:06:59 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 May 2021 16:06:59 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v6] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Thu, 6 May 2021 15:51:36 GMT, Daniel Fuchs wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge >> - Bring back getDescriptor, bzero poll array when initially created >> - epoll_create1 returns NULL on error >> - Remove unused WEPoll.getDescriptor. Update micro to close listener >> - Fix copyright header on SelectOne benchmark >> - Merge >> - Propagate exception from discardOOB, cleanup >> - Merge >> - Use 'to' instead of '(int) timeout >> - Move SelectorWakeup micro to channels directory >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b40c5cb7...260b13fe > > test/micro/org/openjdk/bench/java/nio/channels/SelectOne.java line 71: > >> 69: >> 70: try (ServerSocketChannel listener = ServerSocketChannel.open()) { >> 71: listener.bind(new InetSocketAddress(0)); > > Is using the wildcard really necessary here? I am concerned that the test is relying on unspecified behaviour - namely: > - listener is bound to the wildcard > - listener.getLocalAddress() is *probably* the wildcard > - later SocketChannel is connected using that address which is still *probably* the wildcard. > For the sake of stability - should the test preferably use InetAddress.getLoopbackAddress() for binding and connecting? This is micro rather than a jtreg test so only suitable for running in very controlled environments. I can of course change it to use the loopback address. The original benchmark did that, but I had to strip it down for openjdk/jdk. ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From bpb at openjdk.java.net Thu May 6 16:15:52 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 6 May 2021 16:15:52 GMT Subject: RFR: 8266589: (fs) Improve performance of Files.copy() on macOS using copyfile(3) In-Reply-To: References: Message-ID: On Thu, 6 May 2021 13:19:18 GMT, Alan Bateman wrote: >> Please consider this request to use `fcopyfile(3)` to copy files via `java.nio.file.Files(Path,Path,CopyOption...)` on macOS. This change would improve the throughput of `Files.copy()` as shown in these results: >> >> **Copy via 8192 byte buffers** >> >> >> Benchmark (size) Mode Cnt Score Error Units >> FilesCopy.copy 10240 thrpt 5 5432.671 ? 137.114 ops/s >> FilesCopy.copy 51200 thrpt 5 3959.145 ? 157.467 ops/s >> FilesCopy.copy 102400 thrpt 5 2931.325 ? 109.200 ops/s >> FilesCopy.copy 512000 thrpt 5 655.550 ? 39.919 ops/s >> FilesCopy.copy 1048568 thrpt 5 375.127 ? 10.111 ops/s >> FilesCopy.copy 10485760 thrpt 5 64.048 ? 5.740 ops/s >> FilesCopy.copy 104857600 thrpt 5 6.893 ? 0.415 ops/s >> FilesCopy.copy 1073741824 thrpt 5 0.717 ? 0.026 ops/s >> >> >> **Copy via fcopyfile** >> >> >> Benchmark (size) Mode Cnt Score Error Units >> FilesCopy.copy 10240 thrpt 5 5070.255 ? 817.419 ops/s >> FilesCopy.copy 51200 thrpt 5 4469.218 ? 65.634 ops/s >> FilesCopy.copy 102400 thrpt 5 3997.718 ? 301.440 ops/s >> FilesCopy.copy 512000 thrpt 5 2064.223 ? 68.893 ops/s >> FilesCopy.copy 1048568 thrpt 5 817.743 ? 83.076 ops/s >> FilesCopy.copy 10485760 thrpt 5 145.799 ? 3.674 ops/s >> FilesCopy.copy 104857600 thrpt 5 24.706 ? 14.178 ops/s >> FilesCopy.copy 1073741824 thrpt 5 1.386 ? 0.073 ops/s >> >> >> The smallest size tested shows a small degradation in throughput, but this could be rectified if desired by adding an empirically determined size threshold under which user-space buffers would be used instead of `fcopyfile()`. >> >> A small change is also made to the Linux `sendfile()` portion to use the largest permitted `count` value if the copy is uninterruptible, i.e., `cancel == NULL`. > > src/java.base/unix/native/libnio/fs/UnixCopyFile.c line 65: > >> 63: return COPYFILE_CONTINUE; >> 64: } >> 65: #endif > > I wasn't aware of this fcopyfile but it seems to be a good match. At some point I think we will have to split up UnixCopyFile to make it easier to maintain the different implementations. That might be the opportunity to do more than COPYFILE_DATA, meaning we could get it to copy the meta data too. > > I think we should try to re-format the callback a bit to make it easier to distinguish the conditions in the if-statement from the body. I probably should re-format the declaration too to get it a more more consistent/readable. I agree that it would be good to split it up but as part of a yet to be filed issue. Would you please elaborate on reformatting the callback? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3890 From alanb at openjdk.java.net Thu May 6 18:46:25 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 May 2021 18:46:25 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v7] In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: > This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. > > The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. > > I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). > > Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op > SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op > SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op > SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op > SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op > > > New wepoll based Selector: > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op > SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op > SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op > SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op > SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op > > > Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. > > CSR and Release Note planned. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Update micro to bind to loopback address ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3816/files - new: https://git.openjdk.java.net/jdk/pull/3816/files/260b13fe..fda20ec0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=05-06 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3816/head:pull/3816 PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Thu May 6 18:49:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 May 2021 18:49:50 GMT Subject: RFR: 8266589: (fs) Improve performance of Files.copy() on macOS using copyfile(3) In-Reply-To: References: Message-ID: On Thu, 6 May 2021 16:13:03 GMT, Brian Burkhalter wrote: >> src/java.base/unix/native/libnio/fs/UnixCopyFile.c line 65: >> >>> 63: return COPYFILE_CONTINUE; >>> 64: } >>> 65: #endif >> >> I wasn't aware of this fcopyfile but it seems to be a good match. At some point I think we will have to split up UnixCopyFile to make it easier to maintain the different implementations. That might be the opportunity to do more than COPYFILE_DATA, meaning we could get it to copy the meta data too. >> >> I think we should try to re-format the callback a bit to make it easier to distinguish the conditions in the if-statement from the body. I probably should re-format the declaration too to get it a more more consistent/readable. > > I agree that it would be good to split it up but as part of a yet to be filed issue. > > Would you please elaborate on reformatting the callback? Thanks. I should have been clearer. L58 splits the conditions on two lines with the second line indented 4 spaces so it looks like the 3rd condition is in the block. I think you should re-format it to make it easier to read. ------------- PR: https://git.openjdk.java.net/jdk/pull/3890 From dfuchs at openjdk.java.net Thu May 6 18:50:55 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 6 May 2021 18:50:55 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v7] In-Reply-To: References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: On Thu, 6 May 2021 18:46:25 GMT, Alan Bateman wrote: >> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. >> >> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. >> >> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). >> >> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op >> SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op >> SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op >> SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op >> SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op >> >> >> New wepoll based Selector: >> >> Benchmark (nchannels) Mode Cnt Score Error Units >> SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op >> SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op >> SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op >> SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op >> SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op >> >> >> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. >> >> CSR and Release Note planned. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Update micro to bind to loopback address Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3816 From bpb at openjdk.java.net Thu May 6 18:58:51 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 6 May 2021 18:58:51 GMT Subject: RFR: 8266589: (fs) Improve performance of Files.copy() on macOS using copyfile(3) In-Reply-To: References: Message-ID: On Thu, 6 May 2021 18:46:56 GMT, Alan Bateman wrote: >> I agree that it would be good to split it up but as part of a yet to be filed issue. >> >> Would you please elaborate on reformatting the callback? Thanks. > > I should have been clearer. L58 splits the conditions on two lines with the second line indented 4 spaces so it looks like the 3rd condition is in the block. I think you should re-format it to make it easier to read. This could be made into one line, no split, or three lines. Otherwise an additional `if` would be needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3890 From bpb at openjdk.java.net Thu May 6 19:50:44 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 6 May 2021 19:50:44 GMT Subject: RFR: 8266589: (fs) Improve performance of Files.copy() on macOS using copyfile(3) [v2] In-Reply-To: References: Message-ID: > Please consider this request to use `fcopyfile(3)` to copy files via `java.nio.file.Files(Path,Path,CopyOption...)` on macOS. This change would improve the throughput of `Files.copy()` as shown in these results: > > **Copy via 8192 byte buffers** > > > Benchmark (size) Mode Cnt Score Error Units > FilesCopy.copy 10240 thrpt 5 5432.671 ? 137.114 ops/s > FilesCopy.copy 51200 thrpt 5 3959.145 ? 157.467 ops/s > FilesCopy.copy 102400 thrpt 5 2931.325 ? 109.200 ops/s > FilesCopy.copy 512000 thrpt 5 655.550 ? 39.919 ops/s > FilesCopy.copy 1048568 thrpt 5 375.127 ? 10.111 ops/s > FilesCopy.copy 10485760 thrpt 5 64.048 ? 5.740 ops/s > FilesCopy.copy 104857600 thrpt 5 6.893 ? 0.415 ops/s > FilesCopy.copy 1073741824 thrpt 5 0.717 ? 0.026 ops/s > > > **Copy via fcopyfile** > > > Benchmark (size) Mode Cnt Score Error Units > FilesCopy.copy 10240 thrpt 5 5070.255 ? 817.419 ops/s > FilesCopy.copy 51200 thrpt 5 4469.218 ? 65.634 ops/s > FilesCopy.copy 102400 thrpt 5 3997.718 ? 301.440 ops/s > FilesCopy.copy 512000 thrpt 5 2064.223 ? 68.893 ops/s > FilesCopy.copy 1048568 thrpt 5 817.743 ? 83.076 ops/s > FilesCopy.copy 10485760 thrpt 5 145.799 ? 3.674 ops/s > FilesCopy.copy 104857600 thrpt 5 24.706 ? 14.178 ops/s > FilesCopy.copy 1073741824 thrpt 5 1.386 ? 0.073 ops/s > > > The smallest size tested shows a small degradation in throughput, but this could be rectified if desired by adding an empirically determined size threshold under which user-space buffers would be used instead of `fcopyfile()`. > > A small change is also made to the Linux `sendfile()` portion to use the largest permitted `count` value if the copy is uninterruptible, i.e., `cancel == NULL`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8266589: Handle COPYFILE_ERR stage in fcopyfile_callback() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3890/files - new: https://git.openjdk.java.net/jdk/pull/3890/files/84708f5c..ff2d2f9b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3890&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3890&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3890.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3890/head:pull/3890 PR: https://git.openjdk.java.net/jdk/pull/3890 From jzaugg at openjdk.java.net Fri May 7 03:10:32 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Fri, 7 May 2021 03:10:32 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v5] In-Reply-To: References: Message-ID: > If the given Path represents a file, use the overload of read defined > in FileChannel that accepts an explicit position and avoid serializing > reads. > > Note: The underlying NIO implementation is not required to implement > FileChannel.read(ByteBuffer, long) concurrently; Windows still appears > to lock, as it returns true for NativeDispatcher.needsPositionLock. > > > On MacOS X, the enclosed benchmark improves from: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op > > > To: > > > Benchmark Mode Cnt Score Error Units > ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: [zipfs] Add missing check-failed exception to position/read test This appears to have been omitted when this test was added. To avoid false error reports, the condition must deal with the edge case of zero-length entries, for which read will return -1. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3853/files - new: https://git.openjdk.java.net/jdk/pull/3853/files/c9758c58..9106096e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3853&range=03-04 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3853/head:pull/3853 PR: https://git.openjdk.java.net/jdk/pull/3853 From jzaugg at openjdk.java.net Fri May 7 03:18:12 2021 From: jzaugg at openjdk.java.net (Jason Zaugg) Date: Fri, 7 May 2021 03:18:12 GMT Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v4] In-Reply-To: <2yiP6HEx1W_6XobXJxeo_NuQjFROQpRVZZp8_RP1jrE=.9aa6c044-442e-4435-83b3-bd3f68c3c043@github.com> References: <2yiP6HEx1W_6XobXJxeo_NuQjFROQpRVZZp8_RP1jrE=.9aa6c044-442e-4435-83b3-bd3f68c3c043@github.com> Message-ID: On Thu, 6 May 2021 08:05:12 GMT, Jason Zaugg wrote: >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1235: >> >>> 1233: synchronized(ch) { >>> 1234: return ch.position(pos).read(bb); >>> 1235: } >> >> I think it's okay to include the update to EntryInputStream, that part looks fine, as does the directly use of the FileChannel positional read. >> >> I'm still mulling over the case where ch is not a FileChannel as I would expected it to capture the existing position and restore it after the read. I think this is the degenerative case when the zip file is located in a custom file system that doesn't support FileChannel. In that case, positional read has to be implemented on the most basic SeekableByteChannel. It would only be observed when mixing positional read ops with other ops that depend on the current position. > > Here are all the references to `ch`. > > > this.ch = Files.newByteChannel(zfpath, READ); > ... > this.ch.close(); > ... > ch.close(); // close the ch just in case no update > ... > if (ch instanceof FileChannel fch) { > return fch.read(bb, pos); > } else { > synchronized(ch) { > return ch.position(pos).read(bb); > } > } > ... > long ziplen = ch.size(); > ... > ch.close(); > > > It appears the only position-dependent operation called `read(ByteBuffer)`. This is performed together with the `pos` call within the `synchronized(ch)` lock. I have confirmed that the non-`FileChannel` code path is exercised by existing tests. test/jdk/jdk/nio/zipfs/ZipFSTester.java includes a test that forms a file system based on a JAR that is itself an entry within another `ZipFileSystem`. Sample stacks: java.lang.Throwable: readFullyAt. ch.getClass=class jdk.nio.zipfs.ByteArrayChannel at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.readFullyAt(ZipFileSystem.java:1234) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.readFullyAt(ZipFileSystem.java:1226) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$EntryInputStream.initDataPos(ZipFileSystem.java:2259) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$EntryInputStream.read(ZipFileSystem.java:2201) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$2.fill(ZipFileSystem.java:2151) at java.base/java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158) at ZipFSTester.checkEqual(ZipFSTester.java:858) at ZipFSTester.test1(ZipFSTester.java:259) java.lang.Throwable: readFullyAt. ch.getClass=class jdk.nio.zipfs.ByteArrayChannel at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.readFullyAt(ZipFileSystem.java:1234) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$EntryInputStream.read(ZipFileSystem.java:2214) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$2.fill(ZipFileSystem.java:2151) at java.base/java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158) at ZipFSTester.checkEqual(ZipFSTester.java:858) at ZipFSTester.test1(ZipFSTester.java:259) This use case is not covered by the `ZipFSTester.test2`, a multi-threaded test. While looking at the test I noticed false warnings in the output: `read()/position() failed`. This did not actually fail the test. I investigated this and a) fixed the condition to deal with the edge case of zero-length entries and b) throw an "check failed" exception when the assertion fails. ------------- PR: https://git.openjdk.java.net/jdk/pull/3853 From alanb at openjdk.java.net Fri May 7 05:19:05 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 7 May 2021 05:19:05 GMT Subject: RFR: 8266589: (fs) Improve performance of Files.copy() on macOS using copyfile(3) [v2] In-Reply-To: References: Message-ID: <5DPiuAq1miqh50oOuyUYOnY-rWCLaVTjzbS-pPUCL6Y=.93523ba6-3662-4fc1-8708-e58eab6114cc@github.com> On Thu, 6 May 2021 19:50:44 GMT, Brian Burkhalter wrote: >> Please consider this request to use `fcopyfile(3)` to copy files via `java.nio.file.Files(Path,Path,CopyOption...)` on macOS. This change would improve the throughput of `Files.copy()` as shown in these results: >> >> **Copy via 8192 byte buffers** >> >> >> Benchmark (size) Mode Cnt Score Error Units >> FilesCopy.copy 10240 thrpt 5 5432.671 ? 137.114 ops/s >> FilesCopy.copy 51200 thrpt 5 3959.145 ? 157.467 ops/s >> FilesCopy.copy 102400 thrpt 5 2931.325 ? 109.200 ops/s >> FilesCopy.copy 512000 thrpt 5 655.550 ? 39.919 ops/s >> FilesCopy.copy 1048568 thrpt 5 375.127 ? 10.111 ops/s >> FilesCopy.copy 10485760 thrpt 5 64.048 ? 5.740 ops/s >> FilesCopy.copy 104857600 thrpt 5 6.893 ? 0.415 ops/s >> FilesCopy.copy 1073741824 thrpt 5 0.717 ? 0.026 ops/s >> >> >> **Copy via fcopyfile** >> >> >> Benchmark (size) Mode Cnt Score Error Units >> FilesCopy.copy 10240 thrpt 5 5070.255 ? 817.419 ops/s >> FilesCopy.copy 51200 thrpt 5 4469.218 ? 65.634 ops/s >> FilesCopy.copy 102400 thrpt 5 3997.718 ? 301.440 ops/s >> FilesCopy.copy 512000 thrpt 5 2064.223 ? 68.893 ops/s >> FilesCopy.copy 1048568 thrpt 5 817.743 ? 83.076 ops/s >> FilesCopy.copy 10485760 thrpt 5 145.799 ? 3.674 ops/s >> FilesCopy.copy 104857600 thrpt 5 24.706 ? 14.178 ops/s >> FilesCopy.copy 1073741824 thrpt 5 1.386 ? 0.073 ops/s >> >> >> The smallest size tested shows a small degradation in throughput, but this could be rectified if desired by adding an empirically determined size threshold under which user-space buffers would be used instead of `fcopyfile()`. >> >> A small change is also made to the Linux `sendfile()` portion to use the largest permitted `count` value if the copy is uninterruptible, i.e., `cancel == NULL`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8266589: Handle COPYFILE_ERR stage in fcopyfile_callback() I see the re-examination of the callback means that COPYFILE_ERR is handled now. Good! ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3890 From alanb at openjdk.java.net Fri May 7 07:31:17 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 7 May 2021 07:31:17 GMT Subject: RFR: 8266369: (se) Add wepoll based Selector [v8] In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com> Message-ID: > This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets. > > The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net. > > I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation). > > Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered. > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1587.429 ? 4.053 ns/op > SelectOne.testSelectOne 10 avgt 20 2515.324 ? 8.141 ns/op > SelectOne.testSelectOne 100 avgt 20 10903.445 ? 65.508 ns/op > SelectOne.testSelectOne 1000 avgt 20 101651.369 ? 673.781 ns/op > SelectOne.testSelectOne 10000 avgt 20 932032.385 ? 59004.246 ns/op > > > New wepoll based Selector: > > Benchmark (nchannels) Mode Cnt Score Error Units > SelectOne.testSelectOne 1 avgt 20 1428.914 ? 6.648 ns/op > SelectOne.testSelectOne 10 avgt 20 1429.806 ? 5.537 ns/op > SelectOne.testSelectOne 100 avgt 20 1433.371 ? 3.253 ns/op > SelectOne.testSelectOne 1000 avgt 20 1435.007 ? 12.420 ns/op > SelectOne.testSelectOne 10000 avgt 20 1445.201 ? 7.902 ns/op > > > Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested. > > CSR and Release Note planned. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: - Merge - Windows 32-bit support - Update micro to bind to loopback address - Merge - Bring back getDescriptor, bzero poll array when initially created - epoll_create1 returns NULL on error - Remove unused WEPoll.getDescriptor. Update micro to close listener - Fix copyright header on SelectOne benchmark - Merge - Propagate exception from discardOOB, cleanup - ... and 4 more: https://git.openjdk.java.net/jdk/compare/df57f1bb...d2be1c3a ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3816/files - new: https://git.openjdk.java.net/jdk/pull/3816/files/fda20ec0..d2be1c3a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3816&range=06-07 Stats: 800 lines in 40 files changed: 400 ins; 175 del; 225 mod Patch: https://git.openjdk.java.net/jdk/pull/3816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3816/head:pull/3816 PR: https://git.openjdk.java.net/jdk/pull/3816 From alanb at openjdk.java.net Fri May 7 10:07:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 7 May 2021 10:07:56 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v12] In-Reply-To: <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com> References: <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com> Message-ID: On Thu, 6 May 2021 14:23:27 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java line 72: > 70: * > 71: *
{@code
> 72: try (ResourceScope scope = ResourceScope.ofConfined()) {

The example might be out of date, I assume this should be newConfinedScope.

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

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

From mcimadamore at openjdk.java.net  Fri May  7 11:18:21 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 7 May 2021 11:18:21 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v13]
In-Reply-To: 
References: 
Message-ID: 

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

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

  Fix issue in snippet in package-info

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/926229ed..1ce6366a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=11-12

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

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

From chegar at openjdk.java.net  Fri May  7 13:52:06 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 7 May 2021 13:52:06 GMT
Subject: RFR: 8266369: (se) Add wepoll based Selector [v8]
In-Reply-To: 
References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com>
 
Message-ID: 

On Fri, 7 May 2021 07:31:17 GMT, Alan Bateman  wrote:

>> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets.
>> 
>> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net.
>> 
>> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation).
>> 
>> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered.
>> 
>> Benchmark                (nchannels)  Mode  Cnt       Score       Error  Units
>> SelectOne.testSelectOne            1  avgt   20    1587.429 ?     4.053  ns/op
>> SelectOne.testSelectOne           10  avgt   20    2515.324 ?     8.141  ns/op
>> SelectOne.testSelectOne          100  avgt   20   10903.445 ?    65.508  ns/op
>> SelectOne.testSelectOne         1000  avgt   20  101651.369 ?   673.781  ns/op
>> SelectOne.testSelectOne        10000  avgt   20  932032.385 ? 59004.246  ns/op
>> 
>> 
>> New wepoll based Selector:
>> 
>> Benchmark                (nchannels)  Mode  Cnt     Score    Error  Units
>> SelectOne.testSelectOne            1  avgt   20  1428.914 ?  6.648  ns/op
>> SelectOne.testSelectOne           10  avgt   20  1429.806 ?  5.537  ns/op
>> SelectOne.testSelectOne          100  avgt   20  1433.371 ?  3.253  ns/op
>> SelectOne.testSelectOne         1000  avgt   20  1435.007 ? 12.420  ns/op
>> SelectOne.testSelectOne        10000  avgt   20  1445.201 ?  7.902  ns/op
>> 
>> 
>> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested.
>> 
>> CSR and Release Note planned.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge
>  - Windows 32-bit support
>  - Update micro to bind to loopback address
>  - Merge
>  - Bring back getDescriptor, bzero poll array when initially created
>  - epoll_create1 returns NULL on error
>  - Remove unused WEPoll.getDescriptor. Update micro to close listener
>  - Fix copyright header on SelectOne benchmark
>  - Merge
>  - Propagate exception from discardOOB, cleanup
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/3d433f9c...d2be1c3a

Marked as reviewed by chegar (Reviewer).

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

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

From bpb at openjdk.java.net  Fri May  7 15:27:21 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 7 May 2021 15:27:21 GMT
Subject: Integrated: 8266589: (fs) Improve performance of Files.copy() on
 macOS using copyfile(3)
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 May 2021 20:51:59 GMT, Brian Burkhalter  wrote:

> Please consider this request to use `fcopyfile(3)` to copy files via `java.nio.file.Files(Path,Path,CopyOption...)` on macOS. This change would improve the throughput of `Files.copy()` as shown in these results:
> 
> **Copy via 8192 byte buffers**
> 
> 
> Benchmark           (size)   Mode  Cnt     Score     Error  Units
> FilesCopy.copy       10240  thrpt    5  5432.671 ? 137.114  ops/s
> FilesCopy.copy       51200  thrpt    5  3959.145 ? 157.467  ops/s
> FilesCopy.copy      102400  thrpt    5  2931.325 ? 109.200  ops/s
> FilesCopy.copy      512000  thrpt    5   655.550 ?  39.919  ops/s
> FilesCopy.copy     1048568  thrpt    5   375.127 ?  10.111  ops/s
> FilesCopy.copy    10485760  thrpt    5    64.048 ?   5.740  ops/s
> FilesCopy.copy   104857600  thrpt    5     6.893 ?   0.415  ops/s
> FilesCopy.copy  1073741824  thrpt    5     0.717 ?   0.026  ops/s
> 
> 
> **Copy via fcopyfile**
> 
> 
> Benchmark           (size)   Mode  Cnt     Score     Error  Units
> FilesCopy.copy       10240  thrpt    5  5070.255 ? 817.419  ops/s
> FilesCopy.copy       51200  thrpt    5  4469.218 ?  65.634  ops/s
> FilesCopy.copy      102400  thrpt    5  3997.718 ? 301.440  ops/s
> FilesCopy.copy      512000  thrpt    5  2064.223 ?  68.893  ops/s
> FilesCopy.copy     1048568  thrpt    5   817.743 ?  83.076  ops/s
> FilesCopy.copy    10485760  thrpt    5   145.799 ?   3.674  ops/s
> FilesCopy.copy   104857600  thrpt    5    24.706 ?  14.178  ops/s
> FilesCopy.copy  1073741824  thrpt    5     1.386 ?   0.073  ops/s
> 
> 
> The smallest size tested shows a small degradation in throughput, but this could be rectified if desired by adding an empirically determined size threshold under which user-space buffers would be used instead of `fcopyfile()`.
> 
> A small change is also made to the Linux `sendfile()` portion to use the largest permitted `count` value if the copy is uninterruptible, i.e., `cancel == NULL`.

This pull request has now been integrated.

Changeset: b5b31197
Author:    Brian Burkhalter 
URL:       https://git.openjdk.java.net/jdk/commit/b5b31197e5ab9fda8b9f09367aba280f865d2320
Stats:     42 lines in 1 file changed: 39 ins; 2 del; 1 mod

8266589: (fs) Improve performance of Files.copy() on macOS using copyfile(3)

Reviewed-by: alanb

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

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

From bpb at openjdk.java.net  Fri May  7 22:54:53 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 7 May 2021 22:54:53 GMT
Subject: RFR: 8266369: (se) Add wepoll based Selector [v8]
In-Reply-To: 
References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com>
 
Message-ID: 

On Fri, 7 May 2021 07:31:17 GMT, Alan Bateman  wrote:

>> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets.
>> 
>> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net.
>> 
>> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation).
>> 
>> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered.
>> 
>> Benchmark                (nchannels)  Mode  Cnt       Score       Error  Units
>> SelectOne.testSelectOne            1  avgt   20    1587.429 ?     4.053  ns/op
>> SelectOne.testSelectOne           10  avgt   20    2515.324 ?     8.141  ns/op
>> SelectOne.testSelectOne          100  avgt   20   10903.445 ?    65.508  ns/op
>> SelectOne.testSelectOne         1000  avgt   20  101651.369 ?   673.781  ns/op
>> SelectOne.testSelectOne        10000  avgt   20  932032.385 ? 59004.246  ns/op
>> 
>> 
>> New wepoll based Selector:
>> 
>> Benchmark                (nchannels)  Mode  Cnt     Score    Error  Units
>> SelectOne.testSelectOne            1  avgt   20  1428.914 ?  6.648  ns/op
>> SelectOne.testSelectOne           10  avgt   20  1429.806 ?  5.537  ns/op
>> SelectOne.testSelectOne          100  avgt   20  1433.371 ?  3.253  ns/op
>> SelectOne.testSelectOne         1000  avgt   20  1435.007 ? 12.420  ns/op
>> SelectOne.testSelectOne        10000  avgt   20  1445.201 ?  7.902  ns/op
>> 
>> 
>> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested.
>> 
>> CSR and Release Note planned.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge
>  - Windows 32-bit support
>  - Update micro to bind to loopback address
>  - Merge
>  - Bring back getDescriptor, bzero poll array when initially created
>  - epoll_create1 returns NULL on error
>  - Remove unused WEPoll.getDescriptor. Update micro to close listener
>  - Fix copyright header on SelectOne benchmark
>  - Merge
>  - Propagate exception from discardOOB, cleanup
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/29d66ac3...d2be1c3a

A good improvement. Approved.

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

Marked as reviewed by bpb (Reviewer).

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

From yyang at openjdk.java.net  Sat May  8 03:00:14 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 8 May 2021 03:00:14 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v9]
In-Reply-To: 
References: 
Message-ID: 

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
> 
> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
> 
> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
> 
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
> 
> Testing: cds, compiler and jdk

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

  x86_32 fails

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3615/files
  - new: https://git.openjdk.java.net/jdk/pull/3615/files/f996c99f..307d7a10

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=07-08

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

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

From yyang at openjdk.java.net  Sat May  8 05:36:17 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 8 May 2021 05:36:17 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov  wrote:

> Looks like now the test fails in the pre-submit tests?

Hi Igor,

Can you take a look at the latest version? Now it passes all pre-submit tests.

Best Regards,
Yang

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

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

From yyang at openjdk.java.net  Sat May  8 05:36:17 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 8 May 2021 05:36:17 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com>
References: 
 
 <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com>
Message-ID: <4IY0_Zr94l_aZTe-fYIva28aZw8uYJ5k6d48uByI70E=.19f2b9e5-4958-4bb3-b016-d9f809fe3347@github.com>

On Fri, 30 Apr 2021 17:30:33 GMT, Paul Sandoz  wrote:

> It was my hope this would eventually happen when we added `Objects.checkIndex` and the underlying intrinsic. Very good!

Hi Paul,

Thank you for noticing this PR.
> It was my hope this would eventually happen when we added `Objects.checkIndex` and the underlying intrinsic.
Yes, this patch adds C1 intrinsic supports for checkIndex, I will replace all variants of checkIndex with Objects.checkIndex in follow-up PRs.

It seems that Object.checkIndex can not meet our needs because it implicitly passes null to Preconditions.checkIndex, but we want to customize exception messages, so we might add extra APIs in Objects while doing the replacement.

> Very good!
Thank you Paul~

Best Regards,
Yang

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

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

From alanb at openjdk.java.net  Sat May  8 07:18:02 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 8 May 2021 07:18:02 GMT
Subject: Integrated: 8266369: (se) Add wepoll based Selector
In-Reply-To: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com>
References: <-hwm9SZitbfLQrsJcdXhUFgEnUrxJHH-i42QZy5ve1Q=.ebec11da-ceba-46dd-8870-554d0b83c45f@github.com>
Message-ID: 

On Fri, 30 Apr 2021 14:04:46 GMT, Alan Bateman  wrote:

> This PR proposes a new Selector implementation for the Windows platform based on the Bert Belder's "wepoll" library. The wepoll library provides a scalable polling interface to the Ancillary Function Driver for Winsock. The interface that it exposes is close to the Linux epoll interface. The main benefit is that the cost of selection operations are a function of the number of sockets that are ready for I/O rather than the number of channels registered with the Selector. The existing Selector on Windows uses the legacy "select" which scales horribly, partly because it's O(N) on the number of registered channels and partly because it is limited to 1024 sockets and so requires a thread per 1024 sockets.
> 
> The patch brings the wepoll sources into the repo, adds a small shim, and the Selector implementation itself. The new implementation needs to handle OOB data in the same way as the old implementation so the method to discard OOB moves to Net.
> 
> I've added a microbenchmark to demonstrate the scaling when there is 1, 10, ... 10k connections and one socket ready for I/O. Windows Server 2019 was used for the data here. I've seen improvements with almost everything that I've tried. The only exception is a select after a wakeup where the old implementation skips the selection operation (arguably a long standing bug in the old implementation).
> 
> Existing select based Selector where the selection operation is almost 1ms when there are 10,000 channels registered.
> 
> Benchmark                (nchannels)  Mode  Cnt       Score       Error  Units
> SelectOne.testSelectOne            1  avgt   20    1587.429 ?     4.053  ns/op
> SelectOne.testSelectOne           10  avgt   20    2515.324 ?     8.141  ns/op
> SelectOne.testSelectOne          100  avgt   20   10903.445 ?    65.508  ns/op
> SelectOne.testSelectOne         1000  avgt   20  101651.369 ?   673.781  ns/op
> SelectOne.testSelectOne        10000  avgt   20  932032.385 ? 59004.246  ns/op
> 
> 
> New wepoll based Selector:
> 
> Benchmark                (nchannels)  Mode  Cnt     Score    Error  Units
> SelectOne.testSelectOne            1  avgt   20  1428.914 ?  6.648  ns/op
> SelectOne.testSelectOne           10  avgt   20  1429.806 ?  5.537  ns/op
> SelectOne.testSelectOne          100  avgt   20  1433.371 ?  3.253  ns/op
> SelectOne.testSelectOne         1000  avgt   20  1435.007 ? 12.420  ns/op
> SelectOne.testSelectOne        10000  avgt   20  1445.201 ?  7.902  ns/op
> 
> 
> Replacing the Selector implementation after 19 years of service is a big step. The proposal is to leave the existing implementation until there is confidence with the new implementation. It also serves as a backup in case Windows were to significantly change the AFD interface. The old Selector can be used by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider. A selection of existing tests have been updated to run a second time with the old Selector so that it is continues to be tested.
> 
> CSR and Release Note planned.

This pull request has now been integrated.

Changeset: be4f25b0
Author:    Alan Bateman 
URL:       https://git.openjdk.java.net/jdk/commit/be4f25b0c885a6405b484e4035b30005311a2802
Stats:     3294 lines in 23 files changed: 3192 ins; 60 del; 42 mod

8266369: (se) Add wepoll based Selector

Reviewed-by: chegar, michaelm, vtewari, dfuchs, bpb

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

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

From psandoz at openjdk.java.net  Sat May  8 15:56:05 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Sat, 8 May 2021 15:56:05 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: <4IY0_Zr94l_aZTe-fYIva28aZw8uYJ5k6d48uByI70E=.19f2b9e5-4958-4bb3-b016-d9f809fe3347@github.com>
References: 
 
 <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com>
 <4IY0_Zr94l_aZTe-fYIva28aZw8uYJ5k6d48uByI70E=.19f2b9e5-4958-4bb3-b016-d9f809fe3347@github.com>
Message-ID: 

On Sat, 8 May 2021 05:32:00 GMT, Yi Yang  wrote:

> It seems that Object.checkIndex can not meet our needs because it implicitly passes null to Preconditions.checkIndex, but we want to customize exception messages, so we might add extra APIs in Objects while doing the replacement.
>

It might be possible to directly use `Preconditions.checkIndex` for such purposes, its package is non-exported but public for reuse within `java.base`. It's used in `VarHandle` `byte` array access code, see [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L117).

I would caution against adding a public API to support this. The work in  `Preconditions` was the basis for a public API, but it proved complicated. I am glad we did not expose that, it would of made exposing the long accepting `Objects.checkIndex` methods more difficult.

Paul.

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

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

From lancea at openjdk.java.net  Sun May  9 11:08:46 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 9 May 2021 11:08:46 GMT
Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 03:10:32 GMT, Jason Zaugg  wrote:

>> If the given Path represents a file, use the overload of read defined
>> in FileChannel that accepts an explicit position and avoid serializing
>> reads.
>> 
>> Note: The underlying NIO implementation is not required to implement
>> FileChannel.read(ByteBuffer, long) concurrently; Windows still appears
>> to lock, as it returns true for NativeDispatcher.needsPositionLock.
>> 
>> 
>> On MacOS X, the enclosed benchmark improves from:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  75.311 ? 3.301  ms/op
>> 
>> 
>> To:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  12.520 ? 0.875  ms/op
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [zipfs] Add missing check-failed exception to position/read test
>   
>   This appears to have been omitted when this test was added.
>   To avoid false error reports, the condition must deal with the
>   edge case of zero-length entries, for which read will return -1.

Hi Jason,

I have made a pass through your proposed changes and they look OK.  I am in the process of running our various Mach5 tiers against your patch to see if any unforeseen issues arise

Best
Lance

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

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

From alanb at openjdk.java.net  Sun May  9 15:02:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 9 May 2021 15:02:06 GMT
Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 03:10:32 GMT, Jason Zaugg  wrote:

>> If the given Path represents a file, use the overload of read defined
>> in FileChannel that accepts an explicit position and avoid serializing
>> reads.
>> 
>> Note: The underlying NIO implementation is not required to implement
>> FileChannel.read(ByteBuffer, long) concurrently; Windows still appears
>> to lock, as it returns true for NativeDispatcher.needsPositionLock.
>> 
>> 
>> On MacOS X, the enclosed benchmark improves from:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  75.311 ? 3.301  ms/op
>> 
>> 
>> To:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  12.520 ? 0.875  ms/op
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [zipfs] Add missing check-failed exception to position/read test
>   
>   This appears to have been omitted when this test was added.
>   To avoid false error reports, the condition must deal with the
>   edge case of zero-length entries, for which read will return -1.

Marked as reviewed by alanb (Reviewer).

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

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

From lancea at openjdk.java.net  Mon May 10 10:45:05 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 10 May 2021 10:45:05 GMT
Subject: RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem
 [v5]
In-Reply-To: 
References: 
 
Message-ID: <6GQziWxp_-MON82UG9q0qaLJkmw_zreNfebpdlm5lzc=.c1687e50-28bd-4db5-8695-8ee2920b7ac6@github.com>

On Fri, 7 May 2021 03:10:32 GMT, Jason Zaugg  wrote:

>> If the given Path represents a file, use the overload of read defined
>> in FileChannel that accepts an explicit position and avoid serializing
>> reads.
>> 
>> Note: The underlying NIO implementation is not required to implement
>> FileChannel.read(ByteBuffer, long) concurrently; Windows still appears
>> to lock, as it returns true for NativeDispatcher.needsPositionLock.
>> 
>> 
>> On MacOS X, the enclosed benchmark improves from:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  75.311 ? 3.301  ms/op
>> 
>> 
>> To:
>> 
>> 
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> ZipFileSystemBenchmark.read  avgt   10  12.520 ? 0.875  ms/op
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [zipfs] Add missing check-failed exception to position/read test
>   
>   This appears to have been omitted when this test was added.
>   To avoid false error reports, the condition must deal with the
>   edge case of zero-length entries, for which read will return -1.

Mach5 jdk-tier1, jdk-tier, jdk-tier3 completed successfully

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

Marked as reviewed by lancea (Reviewer).

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

From bpb at openjdk.java.net  Mon May 10 15:59:30 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 10 May 2021 15:59:30 GMT
Subject: RFR: 8266820: micro java/nio/SelectorWakeup.java has wrong copyright
 header
Message-ID: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>

Please review this correction of a copyright header. Thanks.

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

Commit messages:
 - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header
 - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header

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

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

From bpb at openjdk.java.net  Mon May 10 16:10:20 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 10 May 2021 16:10:20 GMT
Subject: RFR: 8266820: micro java/nio/SelectorWakeup.java has wrong
 copyright header [v2]
In-Reply-To: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
References: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
Message-ID: 

> Please review this correction of a copyright header. Thanks.

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

 - Merge
 - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header
 - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header

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

Changes: https://git.openjdk.java.net/jdk/pull/3952/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3952&range=01
  Stats: 28 lines in 1 file changed: 4 ins; 12 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3952.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3952/head:pull/3952

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

From chegar at openjdk.java.net  Mon May 10 16:10:21 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 10 May 2021 16:10:21 GMT
Subject: RFR: 8266820: micro java/nio/SelectorWakeup.java has wrong
 copyright header [v2]
In-Reply-To: 
References: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
 
Message-ID: 

On Mon, 10 May 2021 16:06:52 GMT, Brian Burkhalter  wrote:

>> Please review this correction of a copyright header. Thanks.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge
>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header
>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header

Marked as reviewed by chegar (Reviewer).

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

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

From alanb at openjdk.java.net  Mon May 10 16:10:23 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 10 May 2021 16:10:23 GMT
Subject: RFR: 8266820: micro java/nio/SelectorWakeup.java has wrong
 copyright header [v2]
In-Reply-To: 
References: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
 
Message-ID: 

On Mon, 10 May 2021 16:06:52 GMT, Brian Burkhalter  wrote:

>> Please review this correction of a copyright header. Thanks.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge
>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header
>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header

test/micro/org/openjdk/bench/java/nio/channels/SelectorWakeup.java line 1:

> 1: /*

is your repo up to date? This micro is in the channels directory.

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

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

From bpb at openjdk.java.net  Mon May 10 16:23:58 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 10 May 2021 16:23:58 GMT
Subject: RFR: 8266820: micro java/nio/SelectorWakeup.java has wrong
 copyright header [v2]
In-Reply-To: 
References: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
 
 
Message-ID: 

On Mon, 10 May 2021 16:03:54 GMT, Alan Bateman  wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge
>>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header
>>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header
>
> test/micro/org/openjdk/bench/java/nio/channels/SelectorWakeup.java line 1:
> 
>> 1: /*
> 
> is your repo up to date? This micro is in the channels directory.

Is that not where it is now?

https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/nio/channels

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

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

From bpb at openjdk.java.net  Mon May 10 16:31:26 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 10 May 2021 16:31:26 GMT
Subject: RFR: 8266820: micro java/nio/SelectorWakeup.java has wrong
 copyright header [v2]
In-Reply-To: 
References: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
 
 
 
Message-ID: 

On Mon, 10 May 2021 16:20:33 GMT, Brian Burkhalter  wrote:

>> test/micro/org/openjdk/bench/java/nio/channels/SelectorWakeup.java line 1:
>> 
>>> 1: /*
>> 
>> is your repo up to date? This micro is in the channels directory.
>
> Is that not where it is now?
> 
> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/nio/channels

It was not initially up to date but I merged. I think you were looking at a prior commit.

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

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

From alanb at openjdk.java.net  Mon May 10 16:31:26 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 10 May 2021 16:31:26 GMT
Subject: RFR: 8266820: micro java/nio/SelectorWakeup.java has wrong
 copyright header [v2]
In-Reply-To: 
References: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
 
 
 
 
Message-ID: <-i5RTDNKcUu1WCp9YX0XxiPYY6DCYHKrzc9bJXuX4Vw=.a73d17d4-5e13-460c-a526-4989cf65ae0d@github.com>

On Mon, 10 May 2021 16:24:48 GMT, Brian Burkhalter  wrote:

>> Is that not where it is now?
>> 
>> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/nio/channels
>
> It was not initially up to date but I merged. I think you were looking at a prior commit.

Maybe the bot has fixed the merge conflict. 00-Full suggests you changed the file in the old location, 00-Full suggests you changed the correct file.

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

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

From bpb at openjdk.java.net  Mon May 10 16:31:27 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 10 May 2021 16:31:27 GMT
Subject: RFR: 8266820: micro java/nio/SelectorWakeup.java has wrong
 copyright header [v2]
In-Reply-To: <-i5RTDNKcUu1WCp9YX0XxiPYY6DCYHKrzc9bJXuX4Vw=.a73d17d4-5e13-460c-a526-4989cf65ae0d@github.com>
References: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
 
 
 
 
 <-i5RTDNKcUu1WCp9YX0XxiPYY6DCYHKrzc9bJXuX4Vw=.a73d17d4-5e13-460c-a526-4989cf65ae0d@github.com>
Message-ID: 

On Mon, 10 May 2021 16:25:01 GMT, Alan Bateman  wrote:

>> It was not initially up to date but I merged. I think you were looking at a prior commit.
>
> Maybe the bot has fixed the merge conflict. 00-Full suggests you changed the file in the old location, 00-Full suggests you changed the correct file.

The manual merge fixed it.

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

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

From mcimadamore at openjdk.java.net  Mon May 10 17:45:24 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 17:45:24 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v14]
In-Reply-To: 
References: 
Message-ID: 

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

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

  Remove redundant checks for --enable-native-access

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/1ce6366a..3aaeb09f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=12-13

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

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

From alanb at openjdk.java.net  Mon May 10 18:04:58 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 10 May 2021 18:04:58 GMT
Subject: RFR: 8266820: micro java/nio/SelectorWakeup.java has wrong
 copyright header [v2]
In-Reply-To: 
References: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
 
Message-ID: 

On Mon, 10 May 2021 16:10:20 GMT, Brian Burkhalter  wrote:

>> Please review this correction of a copyright header. Thanks.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge
>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header
>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header

Marked as reviewed by alanb (Reviewer).

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

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

From mcimadamore at openjdk.java.net  Mon May 10 18:15:01 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 18:15:01 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v15]
In-Reply-To: 
References: 
Message-ID: 

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

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

 - Merge branch 'master' into JEP-412
 - Remove redundant checks for --enable-native-access
 - Fix issue in snippet in package-info
 - Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access
 - Fix message string in Reflection::ensureNativeAccess
 - Tweak comment in Module::enableNativeAccess
 - Tweak code some more
 - Use uniform naming convention for implementation metods in Module
 - Remove IllegalNativeAccessChecker
 - Remove redundant initializer in Module
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/bb4038eb...8de9da36

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/3aaeb09f..8de9da36

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=13-14

  Stats: 33173 lines in 668 files changed: 19837 ins; 7268 del; 6068 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

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

From mchung at openjdk.java.net  Mon May 10 19:20:27 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 10 May 2021 19:20:27 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 18:15:01 GMT, Maurizio Cimadamore  wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> 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 23 additional commits since the last revision:
> 
>  - Merge branch 'master' into JEP-412
>  - Remove redundant checks for --enable-native-access
>  - Fix issue in snippet in package-info
>  - Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access
>  - Fix message string in Reflection::ensureNativeAccess
>  - Tweak comment in Module::enableNativeAccess
>  - Tweak code some more
>  - Use uniform naming convention for implementation metods in Module
>  - Remove IllegalNativeAccessChecker
>  - Remove redundant initializer in Module
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/5a35ba03...8de9da36

The caller-sensitive cleanup change looks good.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 148:

> 146:      * @throws IllegalArgumentException in the case of a method type and function descriptor mismatch.
> 147:      * {@code --enable-native-access} is either absent, or does not mention the module name {@code M}, or
> 148:      * {@code ALL-UNNAMED} in case {@code M} is an unnamed module.

line 147-148 are leftover from ICE and they should be removed.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 209:

> 207:      * than the thread owning {@code scope}.
> 208:      * {@code --enable-native-access} is either absent, or does not mention the module name {@code M}, or
> 209:      * {@code ALL-UNNAMED} in case {@code M} is an unnamed module.

line 208-209 are also left-over from the last patch.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractCLinker.java line 44:

> 42:     @CallerSensitive
> 43:     public final MethodHandle downcallHandle(Addressable symbol, MethodType type, FunctionDescriptor function) {
> 44:         Reflection.ensureNativeAccess(Reflection.getCallerClass());

`downcallHandle` method is no longer caller-sensitive.  `@CallerSensitive` and `Reflection.ensureNativeAccess` are no longer needed.    Same for the 4-arg `downcallHandle` method.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/LibrariesHelper.java line 38:

> 36: import jdk.internal.loader.NativeLibrary;
> 37: import jdk.internal.reflect.CallerSensitive;
> 38: import jdk.internal.reflect.Reflection;

I think these 2 imports are no longer used.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Linker.java line 37:

> 35: import jdk.internal.foreign.abi.UpcallStubs;
> 36: import jdk.internal.reflect.CallerSensitive;
> 37: import jdk.internal.reflect.Reflection;

These 2 imports are no longer needed.  Same for other CLinker implementation classes.

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

Marked as reviewed by mchung (Reviewer).

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

From mcimadamore at openjdk.java.net  Mon May 10 20:43:20 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 20:43:20 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
Message-ID: 

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

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

  * Remove unused imports
  * Fix broken javadoc after removal of @throws clauses
  * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/8de9da36..6701654c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=14-15

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

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

From mcimadamore at openjdk.java.net  Mon May 10 20:47:15 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 20:47:15 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
Message-ID: 

On Fri, 30 Apr 2021 17:20:21 GMT, Mandy Chung  wrote:

>>> I think the implementation does not support that. I will also need to look into how this impacts JDK-8266010. As I suggest earlier, I'm fine to do this as a follow up after integration.
>> 
>> I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module).
>> 
>> Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing?
>
>> I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module).
> 
> Thanks.
>  
>> Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing?
> 
> I create JDK-8266383 and I will look into that.

Thanks for the review @mlchung - hopefully looks better now!

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

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

From michaelm at openjdk.java.net  Tue May 11 07:48:13 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 11 May 2021 07:48:13 GMT
Subject: RFR: 8266820: micro java/nio/SelectorWakeup.java has wrong
 copyright header [v2]
In-Reply-To: 
References: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
 
Message-ID: 

On Mon, 10 May 2021 16:10:20 GMT, Brian Burkhalter  wrote:

>> Please review this correction of a copyright header. Thanks.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge
>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header
>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header

Marked as reviewed by michaelm (Reviewer).

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

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

From iris at openjdk.java.net  Tue May 11 15:02:16 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 11 May 2021 15:02:16 GMT
Subject: RFR: 8266820: micro java/nio/SelectorWakeup.java has wrong
 copyright header [v2]
In-Reply-To: 
References: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
 
Message-ID: 

On Mon, 10 May 2021 16:10:20 GMT, Brian Burkhalter  wrote:

>> Please review this correction of a copyright header. Thanks.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge
>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header
>  - 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header

Marked as reviewed by iris (Reviewer).

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

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

From bpb at openjdk.java.net  Tue May 11 16:16:14 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 11 May 2021 16:16:14 GMT
Subject: Integrated: 8266820: micro java/nio/SelectorWakeup.java has wrong
 copyright header
In-Reply-To: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
References: <7AfME5zff7_nO5pypiwPsQne8IuhcAsPQY8P0VqZu-I=.6166dc6b-1b92-498d-b910-6af5cc94295e@github.com>
Message-ID: 

On Mon, 10 May 2021 15:43:26 GMT, Brian Burkhalter  wrote:

> Please review this correction of a copyright header. Thanks.

This pull request has now been integrated.

Changeset: 7a0a57cd
Author:    Brian Burkhalter 
URL:       https://git.openjdk.java.net/jdk/commit/7a0a57cd56a11e4b9e42ac3426f2e0c505da0987
Stats:     28 lines in 1 file changed: 4 ins; 12 del; 12 mod

8266820: micro java/nio/SelectorWakeup.java has wrong copyright header

Reviewed-by: chegar, alanb, michaelm, iris

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

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

From jzaugg at openjdk.java.net  Tue May 11 18:10:01 2021
From: jzaugg at openjdk.java.net (Jason Zaugg)
Date: Tue, 11 May 2021 18:10:01 GMT
Subject: Integrated: 8265448: (zipfs): Reduce read contention in ZipFileSystem
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 May 2021 13:07:34 GMT, Jason Zaugg  wrote:

> If the given Path represents a file, use the overload of read defined
> in FileChannel that accepts an explicit position and avoid serializing
> reads.
> 
> Note: The underlying NIO implementation is not required to implement
> FileChannel.read(ByteBuffer, long) concurrently; Windows still appears
> to lock, as it returns true for NativeDispatcher.needsPositionLock.
> 
> 
> On MacOS X, the enclosed benchmark improves from:
> 
> 
> Benchmark                    Mode  Cnt   Score   Error  Units
> ZipFileSystemBenchmark.read  avgt   10  75.311 ? 3.301  ms/op
> 
> 
> To:
> 
> 
> Benchmark                    Mode  Cnt   Score   Error  Units
> ZipFileSystemBenchmark.read  avgt   10  12.520 ? 0.875  ms/op

This pull request has now been integrated.

Changeset: 0a12605d
Author:    Jason Zaugg 
Committer: Lance Andersen 
URL:       https://git.openjdk.java.net/jdk/commit/0a12605df893d782867529812b1d8c10380f603c
Stats:     108 lines in 3 files changed: 95 ins; 7 del; 6 mod

8265448: (zipfs): Reduce read contention in ZipFileSystem

Reviewed-by: alanb, lancea

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

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

From vlivanov at openjdk.java.net  Wed May 12 14:08:00 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 14:08:00 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 20:43:20 GMT, Maurizio Cimadamore  wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Remove unused imports
>   * Fix broken javadoc after removal of @throws clauses
>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

Overall, hotspot and java.lang.invoke changes look good.

One comment though on naming: there are multiple references to Panama in the code. Moreover, it is used inconsistently (`is_panama_entry_frame()` vs `EntryBlob` vs `OptimizedUpcallStub`). 
I suggest to get rid of any references to Panama and use `optimized`uniformly where appropriate (`is_optimized_entry_frame()`, `OptimizedEntryBlob`, `OptimizedUpcallStub`).

Some minor comments follow.

src/hotspot/share/prims/universalUpcallHandler.cpp line 122:

> 120: JNI_END
> 121: 
> 122: JVM_ENTRY(jlong, PUH_AllocateOptimzedUpcallStub(JNIEnv *env, jclass unused, jobject mh, jobject abi, jobject conv))

Typo: `PUH_AllocateOptimzedUpcallStub` -> `PUH_AllocateOptimizedUpcallStub`.

src/hotspot/share/prims/universalUpcallHandler.cpp line 137:

> 135: JVM_END
> 136: 
> 137: JVM_ENTRY(jboolean, PUH_SupportsOptimzedUpcalls(JNIEnv *env, jclass unused))

Typo: `Optimzed` -> `Optimized`

src/hotspot/share/runtime/sharedRuntime.hpp line 465:

> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
> 464: 
> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);

Please, file an RFE to move these declarations to `MacroAssembler`.

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

Marked as reviewed by vlivanov (Reviewer).

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

From vlivanov at openjdk.java.net  Wed May 12 14:38:18 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 14:38:18 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 20:43:20 GMT, Maurizio Cimadamore  wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Remove unused imports
>   * Fix broken javadoc after removal of @throws clauses
>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:

> 470:   __ block_comment("} preserve_callee_saved_regs ");
> 471: 
> 472:   // TODO mxcsr

Anything left to do with mxcsr?

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

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

From jvernee at openjdk.java.net  Wed May 12 14:58:56 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 12 May 2021 14:58:56 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 12 May 2021 14:06:46 GMT, Vladimir Ivanov  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * Remove unused imports
>>   * Fix broken javadoc after removal of @throws clauses
>>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`
>
> src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:
> 
>> 470:   __ block_comment("} preserve_callee_saved_regs ");
>> 471: 
>> 472:   // TODO mxcsr
> 
> Anything left to do with mxcsr?

I guess this slipped through with the initial PR.

JNI code loads the default value of mxcsr here and saves/restores the incoming native value: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L265-L298

However, it does nothing on Windows, while the Windows x64 ABI also defines mxcsr to have a non-volatile portion (i.e. that should be saved and restored): https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160#mxcsr

I think this made me a bit unsure about the need for saving and restoring mxcsr, and wanted to find an actual test case that causes a problem, rather than just copy-pasting the code (or at least understand it a bit better). But, at this time I haven't gotten to that yet.

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

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

From mcimadamore at openjdk.java.net  Wed May 12 15:11:51 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 12 May 2021 15:11:51 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 12 May 2021 13:57:21 GMT, Vladimir Ivanov  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * Remove unused imports
>>   * Fix broken javadoc after removal of @throws clauses
>>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`
>
> src/hotspot/share/runtime/sharedRuntime.hpp line 465:
> 
>> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
>> 464: 
>> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);
> 
> Please, file an RFE to move these declarations to `MacroAssembler`.

There's already an issue for that:
https://bugs.openjdk.java.net/browse/JDK-8266257

I've upgraded the description to make it reflect the proposed move a bit more precisely.

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

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

From vlivanov at openjdk.java.net  Wed May 12 21:23:55 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 21:23:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
 
Message-ID: <7uT8QeliCJCdi6fuk24JACjroSETna9Y9QxZXep8hMA=.5a392651-605e-48b9-b20f-09b2014d42da@github.com>

On Wed, 12 May 2021 14:53:39 GMT, Jorn Vernee  wrote:

>> src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:
>> 
>>> 470:   __ block_comment("} preserve_callee_saved_regs ");
>>> 471: 
>>> 472:   // TODO mxcsr
>> 
>> Anything left to do with mxcsr?
>
> I guess this slipped through with the initial PR.
> 
> JNI code loads the default value of mxcsr here and saves/restores the incoming native value: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L265-L298
> 
> However, it does nothing on Windows, while the Windows x64 ABI also defines mxcsr to have a non-volatile portion (i.e. that should be saved and restored): https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160#mxcsr
> 
> I think this made me a bit unsure about the need for saving and restoring mxcsr, and wanted to find an actual test case that causes a problem, rather than just copy-pasting the code (or at least understand it a bit better). But, at this time I haven't gotten to that yet.

Thanks for the pointers. It would be safer for now to align the behavior with the call stub.

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

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

From vlivanov at openjdk.java.net  Thu May 13 06:04:00 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 13 May 2021 06:04:00 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 12 May 2021 15:07:37 GMT, Maurizio Cimadamore  wrote:

>> src/hotspot/share/runtime/sharedRuntime.hpp line 465:
>> 
>>> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
>>> 464: 
>>> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);
>> 
>> Please, file an RFE to move these declarations to `MacroAssembler`.
>
> There's already an issue for that:
> https://bugs.openjdk.java.net/browse/JDK-8266257
> 
> I've upgraded the description to make it reflect the proposed move a bit more precisely.

Got it. I was confused by the bug synopsis.

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

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

From mcimadamore at openjdk.java.net  Thu May 13 09:28:27 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 09:28:27 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v17]
In-Reply-To: 
References: 
Message-ID: <2Cgk9O0DjEwy44iJXmyVW_n_Q7mb0XABnlx_G8RYH0E=.f849d10a-2c74-48bc-b092-b43e37ae9574@github.com>

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

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

  Address CSR comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/6701654c..03662920

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=15-16

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

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

From mcimadamore at openjdk.java.net  Thu May 13 10:24:57 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 10:24:57 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v18]
In-Reply-To: 
References: 
Message-ID: 

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

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

 - Take care of remaining references to "Panama"
 - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
   * Replace EntryBlob with OptimizedEntryBlob

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/03662920..3f99cccf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=16-17

  Stats: 45 lines in 15 files changed: 1 ins; 1 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

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

From mcimadamore at openjdk.java.net  Thu May 13 10:55:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 10:55:41 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v19]
In-Reply-To: 
References: 
Message-ID: 

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

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

  Rename is_entry_blob to is_optimized_entry_blob
  Rename as_entry_blob to as_optimized_entry_blob
  Fix misc typos and indentation issues

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/3f99cccf..352c287f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=17-18

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

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

From vlivanov at openjdk.java.net  Thu May 13 10:55:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 13 May 2021 10:55:42 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v19]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 May 2021 10:52:35 GMT, Maurizio Cimadamore  wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename is_entry_blob to is_optimized_entry_blob
>   Rename as_entry_blob to as_optimized_entry_blob
>   Fix misc typos and indentation issues

Marked as reviewed by vlivanov (Reviewer).

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

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

From Alan.Bateman at oracle.com  Fri May 14 14:00:42 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 14 May 2021 15:00:42 +0100
Subject: Need help testing new Selector implementation on Windows
Message-ID: <8f6be9ff-9f3b-430d-9c80-4e31f020ca57@oracle.com>


The implementation of the Selector API on Windows has been replaced in 
JDK 17 b22 with a new more scalable implementation. The old select based 
Selector implementation has been the default since Java 1.4 (2002) so 
replacing it is a significant change. It would be really helpful to get 
more testing of the new implementation before the fork for Rampdown 
Phase One on June 10. If you have an application or workload or tests 
that you know uses the NIO Selector API and can be easily tested on 
Windows then it would be really great if you could spare the time to try 
it out. The JDK 17 Early-Access build page [1] has a download if you 
need it.

Thank you,

-Alan

[1] http://jdk.java.net/17/

From mcimadamore at openjdk.java.net  Mon May 17 16:03:32 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 17 May 2021 16:03:32 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v20]
In-Reply-To: 
References: 
Message-ID: 

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

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

  Fix issue with bounded arena allocator

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/352c287f..0c464221

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=18-19

  Stats: 112 lines in 3 files changed: 61 ins; 37 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

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

From mcimadamore at openjdk.java.net  Mon May 17 16:08:17 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 17 May 2021 16:08:17 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v21]
In-Reply-To: 
References: 
Message-ID: 

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

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

 - Merge branch 'master' into JEP-412
 - Fix issue with bounded arena allocator
 - Rename is_entry_blob to is_optimized_entry_blob
   Rename as_entry_blob to as_optimized_entry_blob
   Fix misc typos and indentation issues
 - Take care of remaining references to "Panama"
 - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
   * Replace EntryBlob with OptimizedEntryBlob
 - Address CSR comments
 - * Remove unused imports
   * Fix broken javadoc after removal of @throws clauses
   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`
 - Merge branch 'master' into JEP-412
 - Remove redundant checks for --enable-native-access
 - Fix issue in snippet in package-info
 - ... and 20 more: https://git.openjdk.java.net/jdk/compare/893e2ec1...9eb61a46

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/0c464221..9eb61a46

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=19-20

  Stats: 23427 lines in 753 files changed: 8549 ins; 9558 del; 5320 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

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

From weijun at openjdk.java.net  Mon May 17 22:01:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:49 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
Message-ID: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>

Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).

With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).

To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:

1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.

Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.

Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.

Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.

There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).

3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).

2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:

rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
 ```

The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

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

Commit messages:
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - test for nio
 - test for hotspot-runtime
 - test for security
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/79b39445...900c28c0

Changes: https://git.openjdk.java.net/jdk/pull/4071/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267184
  Stats: 1024 lines in 852 files changed: 249 ins; 8 del; 767 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

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

From weijun at openjdk.java.net  Mon May 17 22:01:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:52 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for
 Removal
Message-ID: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>

Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).

The code change is divided into 3 commits. Please review them one by one.

1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal

The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.

Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.

Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

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

Commit messages:
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266459
  Stats: 2018 lines in 826 files changed: 1884 ins; 9 del; 125 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

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

From weijun at openjdk.java.net  Mon May 17 22:01:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The 3rd commit is the biggest one but it's all generated programmatically. All changes are simply adding `@SupressWarnings("removal")` to a declaration.

Precisely, of all the diff hunks (leading whitespaces ignored), there are 1607 

+ @SuppressWarnings("removal")


There are also 7 cases where an existing annotation is updated

================= 2 ====================
- @SuppressWarnings("deprecation")
+ @SuppressWarnings({"removal","deprecation"})
================= 1 ====================
- @SuppressWarnings("Convert2Lambda")
+ @SuppressWarnings({"removal","Convert2Lambda"})
================= 1 ====================
- @SuppressWarnings({"unchecked", "CloneDeclaresCloneNotSupported"})
+ @SuppressWarnings({"removal","unchecked", "CloneDeclaresCloneNotSupported"})
================= 1 ====================
- @SuppressWarnings("deprecation") // Use of RMISecurityManager
+ @SuppressWarnings({"removal","deprecation"}) // Use of RMISecurityManager
================= 1 ====================
- @SuppressWarnings("unchecked")     /*To suppress warning from line 1374*/
+ @SuppressWarnings({"removal","unchecked"})     /*To suppress warning from line 1374*/
================= 1 ====================
- @SuppressWarnings("fallthrough")
+ @SuppressWarnings({"removal","fallthrough"})


All other cases are new annotation embedded inline:

================= 7 ====================
- AccessControlContext acc) {
+ @SuppressWarnings("removal") AccessControlContext acc) {
================= 4 ====================
- AccessControlContext acc,
+ @SuppressWarnings("removal") AccessControlContext acc,
================= 3 ====================
- AccessControlContext context,
+ @SuppressWarnings("removal") AccessControlContext context,
================= 3 ====================
- AccessControlContext acc)
+ @SuppressWarnings("removal") AccessControlContext acc)
================= 2 ====================
- try (InputStream stream = AccessController.doPrivileged(pa)) {
+ try (@SuppressWarnings("removal") InputStream stream = AccessController.doPrivileged(pa)) {
================= 2 ====================
- AccessControlContext context, Permission... perms) {
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
================= 2 ====================
- } catch (java.security.AccessControlException e) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException e) {
================= 2 ====================
- } catch (AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") AccessControlException ace) {
================= 2 ====================
- AccessControlContext context)
+ @SuppressWarnings("removal") AccessControlContext context)
================= 2 ====================
- AccessControlContext acc) throws LoginException {
+ @SuppressWarnings("removal") AccessControlContext acc) throws LoginException {
================= 2 ====================
- } catch (AccessControlException e) {
+ } catch (@SuppressWarnings("removal") AccessControlException e) {
================= 1 ====================
- public static void addHook(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ public static void addHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- DomainCombiner combiner,
+ @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- } catch (java.security.AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException ace) {
================= 1 ====================
- private static File checkFile(File f, SecurityManager sm) {
+ private static File checkFile(File f, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static File checkFile(File file, SecurityManager sm) {
+ private static File checkFile(File file, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm,
+ private static void checkPackageAccessForPermittedSubclasses(@SuppressWarnings("removal") SecurityManager sm,
================= 1 ====================
- ProtectionDomain[] getProtectDomains(AccessControlContext context);
+ ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- SecureCallbackHandler(java.security.AccessControlContext acc,
+ SecureCallbackHandler(@SuppressWarnings("removal") java.security.AccessControlContext acc,
================= 1 ====================
- private static void addHookInternal(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ private static void addHookInternal(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- private void checkMemberAccess(SecurityManager sm, int which,
+ private void checkMemberAccess(@SuppressWarnings("removal") SecurityManager sm, int which,
================= 1 ====================
- private static File[] checkFiles(Stream filesStream, SecurityManager sm) {
+ private static File[] checkFiles(Stream filesStream, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- Thread(Runnable target, AccessControlContext acc) {
+ Thread(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public ProtectionDomain[] getProtectDomains(AccessControlContext context) {
+ public ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext stack,
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext stack,
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext(ProtectionDomain caller, DomainCombiner combiner,
+ AccessControlContext(ProtectionDomain caller, @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- public URLClassPath(URL[] urls, AccessControlContext acc) {
+ public URLClassPath(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- URLClassLoader(URL[] urls, AccessControlContext acc) {
+ URLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public static void setSecurityManager(SecurityManager sm) {
+ public static void setSecurityManager(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- try (DataInputStream dis = new DataInputStream(new InflaterInputStream(
+ try (@SuppressWarnings("removal") DataInputStream dis = new DataInputStream(new InflaterInputStream(
================= 1 ====================
- try (FileInputStream fis = AccessController.doPrivileged(
+ try (@SuppressWarnings("removal") FileInputStream fis = AccessController.doPrivileged(
================= 1 ====================
- FactoryURLClassLoader(URL[] urls, AccessControlContext acc) {
+ FactoryURLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- Thread newThreadWithAcc(Runnable target, AccessControlContext acc);
+ Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc);
================= 1 ====================
- SecureRecorderListener(AccessControlContext context, FlightRecorderListener changeListener) {
+ SecureRecorderListener(@SuppressWarnings("removal") AccessControlContext context, FlightRecorderListener changeListener) {
================= 1 ====================
- private PolicyDelegate(PolicySpi spi, Provider p,
+ private PolicyDelegate(@SuppressWarnings("removal") PolicySpi spi, Provider p,
================= 1 ====================
- DomainCombiner combiner) {
+ @SuppressWarnings("removal") DomainCombiner combiner) {
================= 1 ====================
- PrivilegedRunnable(Runnable r, AccessControlContext acc) {
+ PrivilegedRunnable(Runnable r, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private static File[] checkFiles(Stream fs, SecurityManager sm) {
+ private static File[] checkFiles(Stream fs, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private void checkSpecifyHandler(SecurityManager sm) {
+ private void checkSpecifyHandler(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- String serverPrincipal, AccessControlContext acc)
+ String serverPrincipal, @SuppressWarnings("removal") AccessControlContext acc)
================= 1 ====================
- public Thread newThreadWithAcc(Runnable target, AccessControlContext acc) {
+ public Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- try (InputStream is = AccessController.doPrivileged(new PrivilegedAction() {
+ try (@SuppressWarnings("removal") InputStream is = AccessController.doPrivileged(new PrivilegedAction() {
================= 1 ====================
- public EventFileStream(AccessControlContext acc, Path path) throws IOException {
+ public EventFileStream(@SuppressWarnings("removal") AccessControlContext acc, Path path) throws IOException {
================= 1 ====================
- AccessControlContext context, Permission... perms)
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
================= 1 ====================
- private static void privateCheckPackageAccess(SecurityManager s, Class clazz) {
+ private static void privateCheckPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) {
================= 1 ====================
- AbstractEventStream(AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException {
+ AbstractEventStream(@SuppressWarnings("removal") AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException {
================= 1 ====================
- private void checkPackageAccess(SecurityManager sm, final ClassLoader ccl,
+ private void checkPackageAccess(@SuppressWarnings("removal") SecurityManager sm, final ClassLoader ccl,
================= 1 ====================
- AccessControlContext context) {
+ @SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- public PrivilegedExecutor(Executor executor, AccessControlContext acc) {
+ public PrivilegedExecutor(Executor executor, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private RequestHook(AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
+ private RequestHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
================= 1 ====================
- try (BufferedReader bufferedReader =
+ try (@SuppressWarnings("removal") BufferedReader bufferedReader =
================= 1 ====================
- private static void privateCheckProxyPackageAccess(SecurityManager s, Class clazz) {
+ private static void privateCheckProxyPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) {


**That's all**.

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

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

From erikj at openjdk.java.net  Mon May 17 22:30:56 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 17 May 2021 22:30:56 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Makefile change looks ok.

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

Marked as reviewed by erikj (Reviewer).

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

From dholmes at openjdk.java.net  Tue May 18 05:01:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 18 May 2021 05:01:46 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Changes to hotspot-* and serviceability look good.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From alanb at openjdk.java.net  Tue May 18 05:51:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 05:51:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Marked as reviewed by alanb (Reviewer).

The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.

test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.

test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.

For uses using ProcessTools then it seems to be very random.

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

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

From alanb at openjdk.java.net  Tue May 18 06:33:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 06:33:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

src/java.base/share/classes/java/lang/SecurityManager.java line 315:

> 313:  *
> 314:  * @since   1.0
> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a

Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

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

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

From mcimadamore at openjdk.java.net  Tue May 18 10:20:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 18 May 2021 10:20:41 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v22]
In-Reply-To: 
References: 
Message-ID: 

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

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

 - Merge pull request #11 from JornVernee/JEP-412-MXCSR
   
   Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Add MXCSR save and restore to upcall stubs for non-windows platforms

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/9eb61a46..f6051daf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=20-21

  Stats: 32 lines in 1 file changed: 26 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

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

From dfuchs at openjdk.java.net  Tue May 18 11:33:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 18 May 2021 11:33:44 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I looked at serviceability, net, and corelibs. The changes look good to me - though I have one question about the NotificationEmissionTest. I believe that regardless of whether the new property is needed, test case 1 should be run in /othervm too.

test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:

> 32:  * @run clean NotificationEmissionTest
> 33:  * @run build NotificationEmissionTest
> 34:  * @run main NotificationEmissionTest 1

This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

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

Marked as reviewed by dfuchs (Reviewer).

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

From mullan at openjdk.java.net  Tue May 18 12:44:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 12:44:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
> 
>> 313:  *
>> 314:  * @since   1.0
>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
> 
> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

It includes both:
![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

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

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

From weijun at openjdk.java.net  Tue May 18 14:01:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:01:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: 

On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs  wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:
> 
>> 32:  * @run clean NotificationEmissionTest
>> 33:  * @run build NotificationEmissionTest
>> 34:  * @run main NotificationEmissionTest 1
> 
> This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

Or maybe the policy setting line should only be called when a security manager is set? IIRC jtreg is able to restore system properties even in agentvm mode. So maybe this really doesn't matter. We just want to modify as little as possible in this PR.

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

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

From weijun at openjdk.java.net  Tue May 18 14:07:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:07:38 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: 

On Tue, 18 May 2021 05:48:56 GMT, Alan Bateman  wrote:

> The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.
> 
> test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.
> 
> test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.
> 
> For uses using ProcessTools then it seems to be very random.

I've updated the 3 cases you mentioned and will go through more. Yes it looks good to group system property settings together. Thanks.

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

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

From alanb at openjdk.java.net  Tue May 18 15:22:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 15:22:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan  wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
>> 
>>> 313:  *
>>> 314:  * @since   1.0
>>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
>> 
>> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?
>
> It includes both:
> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

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

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

From mullan at openjdk.java.net  Tue May 18 15:49:38 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 15:49:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: <0_9OMaDXfGSSqm5VdlusV4KRWnHxD2KFD5ifyV1hVFI=.1ba2b000-954e-4b23-a869-7d3aa1a909d6@github.com>

On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman  wrote:

>> It includes both:
>> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)
>
> Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

My feeling is that it is better to be more specific than the generic removal text as this is the most significant class that is being deprecated for removal. Also, this says "the Security Manager" (note the space between) which really encompasses more than the `java.lang.SecurityManager` API and which is explained more completely in the JEP.

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

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

From darcy at openjdk.java.net  Tue May 18 16:29:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 18 May 2021 16:29:47 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by darcy (Reviewer).

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

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

From chegar at openjdk.java.net  Tue May 18 16:38:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 18 May 2021 16:38:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The changes in the net area look fine.

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

Marked as reviewed by chegar (Reviewer).

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

From naoto at openjdk.java.net  Tue May 18 16:45:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 18 May 2021 16:45:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Reviewed i18n/java.time/charset. They all look good.

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

Marked as reviewed by naoto (Reviewer).

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

From joehw at openjdk.java.net  Tue May 18 17:30:39 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 18 May 2021 17:30:39 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

java.xml changes look good. Thanks.

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

Marked as reviewed by joehw (Reviewer).

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

From alanb at openjdk.java.net  Tue May 18 17:39:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 17:39:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/security/AccessController.java line 877:

> 875:     @CallerSensitive
> 876:     public static  T doPrivileged(PrivilegedExceptionAction action,
> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

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

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

From mchung at openjdk.java.net  Tue May 18 17:43:39 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:43:39 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I reviewed non-client areas.  Looks okay.

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

Marked as reviewed by mchung (Reviewer).

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

From mchung at openjdk.java.net  Tue May 18 17:53:51 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:53:51 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by mchung (Reviewer).

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

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

From weijun at openjdk.java.net  Tue May 18 18:42:26 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 18:42:26 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/security/AccessController.java line 877:
> 
>> 875:     @CallerSensitive
>> 876:     public static  T doPrivileged(PrivilegedExceptionAction action,
>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
> 
> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

My rule is that a new line is added if there's only whitespaces before the insert position and the previous line does not end with a comma. In this case, unless I move `Permission... perms` onto a new line that an annotation on a new line looks like covering both `context` and `perms`.

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

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

From weijun at openjdk.java.net  Tue May 18 21:13:40 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:13:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang  wrote:

>> src/java.base/share/classes/java/security/AccessController.java line 877:
>> 
>>> 875:     @CallerSensitive
>>> 876:     public static  T doPrivileged(PrivilegedExceptionAction action,
>>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
>> 
>> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.
>
> I'll try to update my auto-annotating program.

Turns out this only happens in this class:

$ rg '^\s*@SuppressWarnings("removal").*?,.'
src/java.base/share/classes/java/security/AccessController.java:449:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:514:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:877:                                     @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

I'll fix them manually.

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

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

From weijun at openjdk.java.net  Tue May 18 21:21:45 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:21:45 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

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

  feedback from Sean, Phil and Alan

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/eb6c566f..bb73093a

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

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

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

From weijun at openjdk.java.net  Tue May 18 21:44:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:44:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

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

  adjust order of VM options

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/900c28c0..bfa955ad

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

  Stats: 59 lines in 18 files changed: 8 ins; 6 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

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

From mcimadamore at openjdk.java.net  Wed May 19 12:15:28 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 19 May 2021 12:15:28 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v23]
In-Reply-To: 
References: 
Message-ID: 

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

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

  Fix VaList test
  Remove unused code in Utils

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/f6051daf..f5668ffc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=21-22

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

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

From weijun at openjdk.java.net  Wed May 19 13:47:54 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:54 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: <8mVaKSBeyfyVBHsp67PuOC1G7--flmHQzygrQTyrgGE=.ed4f6dd9-e0af-4058-97f5-cf5ab3651aa4@github.com>

On Tue, 18 May 2021 21:21:45 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback from Sean, Phil and Alan

A new commit fixing `awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java` test in tier4. The test compares stderr output with a known value but we have a new warning written to stderr now. It's now using stdout instead. @prrace, Please confirm this is acceptable. Thanks.

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

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

From weijun at openjdk.java.net  Wed May 19 13:47:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

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

  fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/bb73093a..c4221b5f

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

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

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

From prr at openjdk.java.net  Wed May 19 18:16:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:16:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

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

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

From prr at openjdk.java.net  Wed May 19 18:19:49 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:19:49 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This change is so large that github won't even display the list of files so I can't jump to where I want to go !
And when I try to scroll I get just a blank page.

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

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

From prr at openjdk.java.net  Wed May 19 18:29:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:29:41 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.desktop/share/classes/java/awt/Component.java line 217:

> 215:  * @author      Sami Shaio
> 216:  */
> 217: @SuppressWarnings("removal")

Why is this placed on the *entire class* ??
This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

src/java.desktop/share/classes/java/awt/Container.java line 97:

> 95:  * @since     1.0
> 96:  */
> 97: @SuppressWarnings("removal")

Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.

Where else are you adding this to entire classes instead of the specific site ?

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

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

From weijun at openjdk.java.net  Wed May 19 18:41:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:41:44 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Wed, 19 May 2021 18:26:25 GMT, Phil Race  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.desktop/share/classes/java/awt/Component.java line 217:
> 
>> 215:  * @author      Sami Shaio
>> 216:  */
>> 217: @SuppressWarnings("removal")
> 
> Why is this placed on the *entire class* ??
> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is

        s = java.security.AccessController.doPrivileged(
                                                        new GetPropertyAction("awt.image.redrawrate"));

> src/java.desktop/share/classes/java/awt/Container.java line 97:
> 
>> 95:  * @since     1.0
>> 96:  */
>> 97: @SuppressWarnings("removal")
> 
> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
> 
> Where else are you adding this to entire classes instead of the specific site ?

Similar as the one above, it's because of

    static {
        // Don't lazy-read because every app uses invalidate()
        isJavaAwtSmartInvalidate = AccessController.doPrivileged(
                new GetBooleanAction("java.awt.smartInvalidate"));
    }

> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
>> 57:                 ProcessCommunicator
>> 58:                         .executeChildProcess(Consumer.class, new String[0]);
>> 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

The child process is started with `-Djava.security.manager=allow` (after the other PR) and a warning will be printed to stderr. Therefore I move the message to stdout.

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

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

From weijun at openjdk.java.net  Wed May 19 18:46:46 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:46:46 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: 

On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang  wrote:

>> src/java.desktop/share/classes/java/awt/Container.java line 97:
>> 
>>> 95:  * @since     1.0
>>> 96:  */
>>> 97: @SuppressWarnings("removal")
>> 
>> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
>> 
>> Where else are you adding this to entire classes instead of the specific site ?
>
> Similar as the one above, it's because of
> 
>     static {
>         // Don't lazy-read because every app uses invalidate()
>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>                 new GetBooleanAction("java.awt.smartInvalidate"));
>     }

We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

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

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

From weijun at openjdk.java.net  Wed May 19 18:51:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:51:43 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 
Message-ID: 

On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang  wrote:

>> Similar as the one above, it's because of
>> 
>>     static {
>>         // Don't lazy-read because every app uses invalidate()
>>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>>                 new GetBooleanAction("java.awt.smartInvalidate"));
>>     }
>
> We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

I know it's not easy to read the commit and that's why I make the 3rd commit totally automatic. Hopefully you have more confidence on the program than my hand. All annotations are added to the nearest declarations.

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

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

From prr at openjdk.java.net  Wed May 19 19:34:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 19:34:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>

On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang  wrote:

>> src/java.desktop/share/classes/java/awt/Component.java line 217:
>> 
>>> 215:  * @author      Sami Shaio
>>> 216:  */
>>> 217: @SuppressWarnings("removal")
>> 
>> Why is this placed on the *entire class* ??
>> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.
>
> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
> 
>         s = java.security.AccessController.doPrivileged(
>                                                         new GetPropertyAction("awt.image.redrawrate"));

That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
You can define a static private method to contain this and call it from the static initializer block.
Much better than applying the annotation to an entire class.

--- a/src/java.desktop/share/classes/java/awt/Component.java
+++ b/src/java.desktop/share/classes/java/awt/Component.java
@@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
      */
     static boolean isInc;
     static int incRate;
+
+    private static void initIncRate() {
+        String s = java.security.AccessController.doPrivileged(
+                                 new GetPropertyAction("awt.image.incrementaldraw"));
+        isInc = (s == null || s.equals("true"));
+
+        s = java.security.AccessController.doPrivileged(
+                          new GetPropertyAction("awt.image.redrawrate"));
+        incRate = (s != null) ? Integer.parseInt(s) : 100;
+    }
+
     static {
         /* ensure that the necessary native libraries are loaded */
         Toolkit.loadLibraries();
@@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
         if (!GraphicsEnvironment.isHeadless()) {
             initIDs();
         }
-
-        String s = java.security.AccessController.doPrivileged(
-                                                               new GetPropertyAction("awt.image.incrementaldraw"));
-        isInc = (s == null || s.equals("true"));
-
-        s = java.security.AccessController.doPrivileged(
-                                                        new GetPropertyAction("awt.image.redrawrate"));
-        incRate = (s != null) ? Integer.parseInt(s) : 100;
+        initIncRate();
     }

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

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

From mullan at openjdk.java.net  Wed May 19 20:33:43 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 19 May 2021 20:33:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: 

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang  wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The changes to the security tests look good.

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

Marked as reviewed by mullan (Reviewer).

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

From simone.bordet at gmail.com  Wed May 19 21:28:36 2021
From: simone.bordet at gmail.com (Simone Bordet)
Date: Wed, 19 May 2021 23:28:36 +0200
Subject: Need help testing new Selector implementation on Windows
In-Reply-To: <8f6be9ff-9f3b-430d-9c80-4e31f020ca57@oracle.com>
References: <8f6be9ff-9f3b-430d-9c80-4e31f020ca57@oracle.com>
Message-ID: 

Alan et al.,

On Fri, May 14, 2021 at 4:01 PM Alan Bateman  wrote:
>
>
> The implementation of the Selector API on Windows has been replaced in
> JDK 17 b22 with a new more scalable implementation. The old select based
> Selector implementation has been the default since Java 1.4 (2002) so
> replacing it is a significant change. It would be really helpful to get
> more testing of the new implementation before the fork for Rampdown
> Phase One on June 10. If you have an application or workload or tests
> that you know uses the NIO Selector API and can be easily tested on
> Windows then it would be really great if you could spare the time to try
> it out. The JDK 17 Early-Access build page [1] has a download if you
> need it.

We have setup a Jetty 10 + OpenJDK 17+22 on our Jenkins:
https://jenkins.webtide.net/job/nightlies/job/jetty-10.0.x-windows-nightly-jdk17/

There are a few tests failing mostly due to filesystem differences
(deleting files that are in use, etc.) so it's not the cleanest of the
builds, but we'll try to spend some time on it to improve it.
The NIO code is tested quite thoroughly though.
I'm assuming the new implementation is the default and there is
nothing to configure to enable it, right?

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From weijun at openjdk.java.net  Wed May 19 21:56:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 21:56:30 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
Message-ID: 

On Wed, 19 May 2021 19:31:24 GMT, Phil Race  wrote:

>> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
>> 
>>         s = java.security.AccessController.doPrivileged(
>>                                                         new GetPropertyAction("awt.image.redrawrate"));
>
> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
> You can define a static private method to contain this and call it from the static initializer block.
> Much better than applying the annotation to an entire class.
> 
> --- a/src/java.desktop/share/classes/java/awt/Component.java
> +++ b/src/java.desktop/share/classes/java/awt/Component.java
> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>       */
>      static boolean isInc;
>      static int incRate;
> +
> +    private static void initIncRate() {
> +        String s = java.security.AccessController.doPrivileged(
> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
> +        isInc = (s == null || s.equals("true"));
> +
> +        s = java.security.AccessController.doPrivileged(
> +                          new GetPropertyAction("awt.image.redrawrate"));
> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +    }
> +
>      static {
>          /* ensure that the necessary native libraries are loaded */
>          Toolkit.loadLibraries();
> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>          if (!GraphicsEnvironment.isHeadless()) {
>              initIDs();
>          }
> -
> -        String s = java.security.AccessController.doPrivileged(
> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
> -        isInc = (s == null || s.equals("true"));
> -
> -        s = java.security.AccessController.doPrivileged(
> -                                                        new GetPropertyAction("awt.image.redrawrate"));
> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +        initIncRate();
>      }

Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

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

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

From prr at openjdk.java.net  Wed May 19 22:07:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 22:07:36 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
Message-ID: 

On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang  wrote:

>> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
>> You can define a static private method to contain this and call it from the static initializer block.
>> Much better than applying the annotation to an entire class.
>> 
>> --- a/src/java.desktop/share/classes/java/awt/Component.java
>> +++ b/src/java.desktop/share/classes/java/awt/Component.java
>> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>       */
>>      static boolean isInc;
>>      static int incRate;
>> +
>> +    private static void initIncRate() {
>> +        String s = java.security.AccessController.doPrivileged(
>> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
>> +        isInc = (s == null || s.equals("true"));
>> +
>> +        s = java.security.AccessController.doPrivileged(
>> +                          new GetPropertyAction("awt.image.redrawrate"));
>> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +    }
>> +
>>      static {
>>          /* ensure that the necessary native libraries are loaded */
>>          Toolkit.loadLibraries();
>> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>          if (!GraphicsEnvironment.isHeadless()) {
>>              initIDs();
>>          }
>> -
>> -        String s = java.security.AccessController.doPrivileged(
>> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
>> -        isInc = (s == null || s.equals("true"));
>> -
>> -        s = java.security.AccessController.doPrivileged(
>> -                                                        new GetPropertyAction("awt.image.redrawrate"));
>> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +        initIncRate();
>>      }
>
> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
I think it should all be taken care of as part of this proposed change.

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

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

From weijun at openjdk.java.net  Wed May 19 22:17:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 22:17:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
Message-ID: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>

On Wed, 19 May 2021 22:04:57 GMT, Phil Race  wrote:

>> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.
>
> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
> I think it should all be taken care of as part of this proposed change.

I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

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

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

From prr at openjdk.java.net  Wed May 19 23:53:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 23:53:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
Message-ID: 

On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang  wrote:

>> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
I already pasted the patch for Component.java and it took about 60 seconds to do that.
Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.

I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

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

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

From weijun at openjdk.java.net  Thu May 20 02:09:42 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:09:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
Message-ID: 

On Wed, 19 May 2021 23:50:04 GMT, Phil Race  wrote:

>> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.
>
> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
> I already pasted the patch for Component.java and it took about 60 seconds to do that.
> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
> 
> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

I can make it a bug.

I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.

And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.

Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

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

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

From weijun at openjdk.java.net  Thu May 20 02:12:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:12:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
Message-ID: 

On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang  wrote:

>> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
>> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
>> I already pasted the patch for Component.java and it took about 60 seconds to do that.
>> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
>> 
>> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?
>
> I can make it a bug.
> 
> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
> 
> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
> 
> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

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

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

From prr at openjdk.java.net  Thu May 20 04:08:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:08:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
Message-ID: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>

On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang  wrote:

>> I can make it a bug.
>> 
>> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
>> 
>> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
>> 
>> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.
>
> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

That is unfortunate, but nonetheless I think required to be done.
We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>From my point of view it is a blocker.

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

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

From prr at openjdk.java.net  Thu May 20 04:25:29 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:25:29 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
Message-ID: 

On Thu, 20 May 2021 04:05:23 GMT, Phil Race  wrote:

>> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.
>
> That is unfortunate, but nonetheless I think required to be done.
> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
> From my point of view it is a blocker.

The JEP isn't PTT for 17 so there's plenty of time isn't there ?

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu May 20 06:45:43 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 20 May 2021 06:45:43 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ???????  wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

Any more comments?

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

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

From alanb at openjdk.java.net  Thu May 20 07:08:35 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 20 May 2021 07:08:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 
Message-ID: 

On Thu, 20 May 2021 04:22:32 GMT, Phil Race  wrote:

>> That is unfortunate, but nonetheless I think required to be done.
>> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>> From my point of view it is a blocker.
>
> The JEP isn't PTT for 17 so there's plenty of time isn't there ?

There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

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

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

From Alan.Bateman at oracle.com  Thu May 20 07:47:47 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 20 May 2021 08:47:47 +0100
Subject: Need help testing new Selector implementation on Windows
In-Reply-To: 
References: <8f6be9ff-9f3b-430d-9c80-4e31f020ca57@oracle.com>
 
Message-ID: <33a84145-1186-7d82-4a26-934f2d7bd35d@oracle.com>

On 19/05/2021 22:28, Simone Bordet wrote:
> We have setup a Jetty 10 + OpenJDK 17+22 on our Jenkins:
> https://jenkins.webtide.net/job/nightlies/job/jetty-10.0.x-windows-nightly-jdk17/
>
> There are a few tests failing mostly due to filesystem differences
> (deleting files that are in use, etc.) so it's not the cleanest of the
> builds, but we'll try to spend some time on it to improve it.
> The NIO code is tested quite thoroughly though.
> I'm assuming the new implementation is the default and there is
> nothing to configure to enable it, right?
>
Yes, it's the default so no system property or other switch.

It's good to see that this Jenkins jobs is setup, thanks for that. The 
call for additional helping test is mostly to make sure that swapping 
out the underlying implementation doesn't change behavior or introduce a 
regression. It would be a bonus to get more performance testing. We 
expect the new implementation to scale significantly much better than 
the old implementation as the number of registered socket channels 
increases.

-Alan

From simone.bordet at gmail.com  Thu May 20 07:53:33 2021
From: simone.bordet at gmail.com (Simone Bordet)
Date: Thu, 20 May 2021 09:53:33 +0200
Subject: Need help testing new Selector implementation on Windows
In-Reply-To: <33a84145-1186-7d82-4a26-934f2d7bd35d@oracle.com>
References: <8f6be9ff-9f3b-430d-9c80-4e31f020ca57@oracle.com>
 
 <33a84145-1186-7d82-4a26-934f2d7bd35d@oracle.com>
Message-ID: 

Hi,

On Thu, May 20, 2021 at 9:47 AM Alan Bateman  wrote:
>
> On 19/05/2021 22:28, Simone Bordet wrote:
> > We have setup a Jetty 10 + OpenJDK 17+22 on our Jenkins:
> > https://jenkins.webtide.net/job/nightlies/job/jetty-10.0.x-windows-nightly-jdk17/
> >
> > There are a few tests failing mostly due to filesystem differences
> > (deleting files that are in use, etc.) so it's not the cleanest of the
> > builds, but we'll try to spend some time on it to improve it.
> > The NIO code is tested quite thoroughly though.
> > I'm assuming the new implementation is the default and there is
> > nothing to configure to enable it, right?
> >
> Yes, it's the default so no system property or other switch.
>
> It's good to see that this Jenkins jobs is setup, thanks for that. The
> call for additional helping test is mostly to make sure that swapping
> out the underlying implementation doesn't change behavior or introduce a
> regression. It would be a bonus to get more performance testing. We
> expect the new implementation to scale significantly much better than
> the old implementation as the number of registered socket channels
> increases.

We are doing some performance testing, but I can't promise we will do
them on Windows :)

In case we do, I'll follow up.

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From redestad at openjdk.java.net  Thu May 20 10:45:37 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 20 May 2021 10:45:37 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ???????  wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

Marked as reviewed by redestad (Reviewer).

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

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

From mcimadamore at openjdk.java.net  Thu May 20 13:05:22 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 20 May 2021 13:05:22 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: 
References: 
Message-ID: 

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

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

 - Add sealed modifiers in morally sealed API interfaces
 - Merge branch 'master' into JEP-412
 - Fix VaList test
   Remove unused code in Utils
 - Merge pull request #11 from JornVernee/JEP-412-MXCSR
   
   Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Merge branch 'master' into JEP-412
 - Fix issue with bounded arena allocator
 - Rename is_entry_blob to is_optimized_entry_blob
   Rename as_entry_blob to as_optimized_entry_blob
   Fix misc typos and indentation issues
 - Take care of remaining references to "Panama"
 - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
   * Replace EntryBlob with OptimizedEntryBlob
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/788875f9...e927c235

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/f5668ffc..e927c235

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=22-23

  Stats: 7087 lines in 360 files changed: 4302 ins; 1796 del; 989 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

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

From mcimadamore at openjdk.java.net  Thu May 20 13:05:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 20 May 2021 13:05:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: 
References: 
 
Message-ID: <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com>

On Thu, 20 May 2021 13:00:15 GMT, Maurizio Cimadamore  wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> 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 35 additional commits since the last revision:
> 
>  - Add sealed modifiers in morally sealed API interfaces
>  - Merge branch 'master' into JEP-412
>  - Fix VaList test
>    Remove unused code in Utils
>  - Merge pull request #11 from JornVernee/JEP-412-MXCSR
>    
>    Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Merge branch 'master' into JEP-412
>  - Fix issue with bounded arena allocator
>  - Rename is_entry_blob to is_optimized_entry_blob
>    Rename as_entry_blob to as_optimized_entry_blob
>    Fix misc typos and indentation issues
>  - Take care of remaining references to "Panama"
>  - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
>    * Replace EntryBlob with OptimizedEntryBlob
>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/629f67e6...e927c235

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 200:

> 198:  * Implementations of this interface are immutable, thread-safe and value-based.
> 199:  */
> 200: public sealed interface MemoryLayout extends Constable permits AbstractLayout, SequenceLayout, GroupLayout, PaddingLayout, ValueLayout {

In principle we could just permit AbstractLayout and be done. In practice, the javadoc comes out better if we list all the concrete API interfaces which extend MemoryLayout, as the `permit` list will be displayed in the javadoc.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu May 20 13:07:34 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 20 May 2021 13:07:34 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <-6K32RgKOwmXJztestBAA8OWC406eWVuqTRIjvfzcoQ=.59f5b0be-a1d9-48a8-89bd-5b7c51222bd7@github.com>

On Thu, 20 May 2021 10:42:49 GMT, Claes Redestad  wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8261880: Remove static from declarations of Holder nested classes
>
> Marked as reviewed by redestad (Reviewer).

@cl4es now you can sponsor :)

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

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

From mcimadamore at openjdk.java.net  Thu May 20 13:12:09 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 20 May 2021 13:12:09 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: 
References: 
 
Message-ID: <9PaAroygCBAEwYmF4lNFzy46QKSPJsET65dXf6XQs18=.9059eafa-0dae-4a6c-ab12-461bb6456b92@github.com>

On Thu, 20 May 2021 13:05:22 GMT, Maurizio Cimadamore  wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> 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 35 additional commits since the last revision:
> 
>  - Add sealed modifiers in morally sealed API interfaces
>  - Merge branch 'master' into JEP-412
>  - Fix VaList test
>    Remove unused code in Utils
>  - Merge pull request #11 from JornVernee/JEP-412-MXCSR
>    
>    Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Merge branch 'master' into JEP-412
>  - Fix issue with bounded arena allocator
>  - Rename is_entry_blob to is_optimized_entry_blob
>    Rename as_entry_blob to as_optimized_entry_blob
>    Fix misc typos and indentation issues
>  - Take care of remaining references to "Panama"
>  - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
>    * Replace EntryBlob with OptimizedEntryBlob
>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/354e6edf...e927c235

Latest javadoc:
http://cr.openjdk.java.net/~mcimadamore/JEP-412/v3/javadoc/jdk/incubator/foreign/package-summary.html
Latest specdiff:
http://cr.openjdk.java.net/~mcimadamore/JEP-412/v3/specdiff/overview-summary.html

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

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

From jvernee at openjdk.java.net  Thu May 20 13:12:26 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 20 May 2021 13:12:26 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com>
References: 
 
 <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com>
Message-ID: 

On Thu, 20 May 2021 13:00:14 GMT, Maurizio Cimadamore  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 35 additional commits since the last revision:
>> 
>>  - Add sealed modifiers in morally sealed API interfaces
>>  - Merge branch 'master' into JEP-412
>>  - Fix VaList test
>>    Remove unused code in Utils
>>  - Merge pull request #11 from JornVernee/JEP-412-MXCSR
>>    
>>    Add MXCSR save and restore to upcall stubs for non-windows platforms
>>  - Add MXCSR save and restore to upcall stubs for non-windows platforms
>>  - Merge branch 'master' into JEP-412
>>  - Fix issue with bounded arena allocator
>>  - Rename is_entry_blob to is_optimized_entry_blob
>>    Rename as_entry_blob to as_optimized_entry_blob
>>    Fix misc typos and indentation issues
>>  - Take care of remaining references to "Panama"
>>  - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
>>    * Replace EntryBlob with OptimizedEntryBlob
>>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/26a8cf83...e927c235
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 200:
> 
>> 198:  * Implementations of this interface are immutable, thread-safe and value-based.
>> 199:  */
>> 200: public sealed interface MemoryLayout extends Constable permits AbstractLayout, SequenceLayout, GroupLayout, PaddingLayout, ValueLayout {
> 
> In principle we could just permit AbstractLayout and be done. In practice, the javadoc comes out better if we list all the concrete API interfaces which extend MemoryLayout, as the `permit` list will be displayed in the javadoc.

At least the internal class name is hidden in the javadoc:
![image](https://user-images.githubusercontent.com/5962029/118983890-37042080-b97d-11eb-9ee0-ae5d5db5cd7e.png)

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

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

From github.com+1324414+desruisseaux at openjdk.java.net  Thu May 20 13:18:36 2021
From: github.com+1324414+desruisseaux at openjdk.java.net (Martin Desruisseaux)
Date: Thu, 20 May 2021 13:18:36 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ???????  wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

Just for information there is similar issues in `javax.imageio.metadata.IIOMetadataFormatImpl` class in the `java.desktop` module.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu May 20 13:59:41 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 20 May 2021 13:59:41 GMT
Subject: Integrated: 8261880: Change nested classes in java.base to static
 nested classes where possible
In-Reply-To: 
References: 
Message-ID: 

On Tue, 16 Feb 2021 14:30:58 GMT, ?????? ???????  wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.

This pull request has now been integrated.

Changeset: 9425d3de
Author:    Sergey Tsypanov 
Committer: Claes Redestad 
URL:       https://git.openjdk.java.net/jdk/commit/9425d3de83fe8f4caddef03ffa3f4dd4de58f236
Stats:     15 lines in 11 files changed: 0 ins; 0 del; 15 mod

8261880: Change nested classes in java.base to static nested classes where possible

Reviewed-by: redestad

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

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

From alanb at openjdk.java.net  Thu May 20 17:45:45 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 20 May 2021 17:45:45 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: 
References: 
 <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com>
 
Message-ID: <8LA0NkO48Sxqf8ITGs8HWtyQhcr5oK5sbMBcYYOZCe0=.5c378205-caed-467e-9dc3-999b5dd54b05@github.com>

On Wed, 28 Apr 2021 08:20:05 GMT, Chris Hegarty  wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466:
>> 
>>> 464:     }
>>> 465: 
>>> 466:     private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess();
>> 
>> It might be cleaner to move to acquire/release methods to their own supporting class as it's not really IOUtil.
>
> I went back and forth on this a number of times already. I think where we landed is a reasonable place, given the current shape of the code.
> 
> Scope is a private property of Buffer, and as such should be consulted anywhere where a buffer's address is being accessed. In fact, a prior prototype would not allow access to the underlying address value without the caller passing a valid handle for the buffer view's scope. It's hard to find the sweet-spot here between code reuse and safety, but the high-order bit is that the code accessing the address is auditable and testable to avoid accessing memory unsafely. Maybe there is a better alternative implementation code structure (at the cost of some duplication), but it is not obvious to me what that is (and I have given it some thought). Suggestions welcome.
> 
> Note, there is a little more follow-on work to be done in this area, if we are to expand support to other non-TCP channel implementations. Maybe investigation into possible code refactorings could be done as part of that?

Can you create a follow-on issue to re-visit the changes to IOUtil? The changes in this area that are in this PR will need to re-worked so that it more cleanly separate the synchronous and asynchronous usages.

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

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

From kcr at openjdk.java.net  Thu May 20 18:31:33 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 20 May 2021 18:31:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: <58-JOVfSiUl3xFtcjGhwaviPqV-amDLlusvj_yCwmj8=.6d3bbada-4a59-443a-9940-121606b64a71@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This isn't a review of the code changes, although I did take a quick look at the manual changes, and they look fine.

I did a local build of the PR branch on Windows, Mac, and Linux, and then did a build / test of JavaFX using that locally built JDK to find all the places where I need to add `-Djava.security.manager=allow` to the JavaFX tests to fix [JDK-8264140](https://bugs.openjdk.java.net/browse/JDK-8264140). It's working as expected.

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

Marked as reviewed by kcr (Author).

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

From github.com+10835776+stsypanov at openjdk.java.net  Fri May 21 14:04:23 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 21 May 2021 14:04:23 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com>

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ???????  wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

Hi guys, any more comments here? Please ping me if I've missed something

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

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

From alanb at openjdk.java.net  Fri May 21 14:26:50 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 21 May 2021 14:26:50 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com>
Message-ID: <7M39TjBM4Y3jcrY8TSkasy25HcSB8WqKOVu_JK5c4mU=.122ac5e0-50e5-4bf6-80ae-e32337c6938d@github.com>

On Fri, 21 May 2021 13:13:04 GMT, ?????? ???????  wrote:

> Hi guys, any more comments here? Please ping me if I've missed something

I suspect this will require renaming some fields and changing comments, e.g. requestList is no longer a good name for the field in AbstractPoller, its comments need changes too. The field in ResolverConfigurationImpl is searchList, it will require a few changes. There may be more, I just picked out a few.

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

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

From dfuchs at openjdk.java.net  Fri May 21 14:26:48 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 14:26:48 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: 

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ???????  wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements?

I am not convinced that a global replacement of  `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient.

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 155:

> 153:      */
> 154:     public List get(String fileName) {
> 155:         ArrayList jarFiles;

This could probably be declared as:


List jarFiles;

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 264:

> 262:                 String jar = jarFiles[i];
> 263:                 bw.write(jar + "\n");
> 264:                 ArrayList jarlist = jarMap.get(jar);

Here again, jarList could probably be declared as `List`

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

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

From github.com+13357965+thihup at openjdk.java.net  Fri May 21 14:55:16 2021
From: github.com+13357965+thihup at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 21 May 2021 14:55:16 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: 

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ???????  wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 154:

> 152:      * @param fileName the key of the mapping
> 153:      */
> 154:     public List get(String fileName) {

IcedTea-Web seems to be using this method reflectively:
https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80

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

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

From alanb at openjdk.java.net  Fri May 21 15:02:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 21 May 2021 15:02:57 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
Message-ID: 

On Fri, 21 May 2021 14:52:21 GMT, Thiago Henrique H?pner  wrote:

> IcedTea-Web seems to be using this method reflectively:
> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80

I assume this doesn't work with JDK 16, at least not without using --add-options to export jdk.internal.util.jar.

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

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

From github.com+13357965+thihup at openjdk.java.net  Fri May 21 15:15:15 2021
From: github.com+13357965+thihup at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 21 May 2021 15:15:15 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 15:00:15 GMT, Alan Bateman  wrote:

>> src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 154:
>> 
>>> 152:      * @param fileName the key of the mapping
>>> 153:      */
>>> 154:     public List get(String fileName) {
>> 
>> IcedTea-Web seems to be using this method reflectively:
>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
>
>> IcedTea-Web seems to be using this method reflectively:
>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
> 
> I assume this doesn't work with JDK 16, at least not without using --add-options to export jdk.internal.util.jar.

Just for completeness, they're using the add-exports:
https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19

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

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

From dfuchs at openjdk.java.net  Fri May 21 15:36:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:36:08 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.base/share/classes/java/lang/SecurityManager.java line 104:

> 102:  * method will throw an {@code UnsupportedOperationException}). If the
> 103:  * {@systemProperty java.security.manager} system property is set to the
> 104:  * special token "{@code allow}", then a security manager will not be set at

Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

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

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

From prr at openjdk.java.net  Fri May 21 18:03:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:03:01 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 
 
Message-ID: 

On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman  wrote:

>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
It is very straight forward to run the automated tests across all platforms these days.
I get the impression that no one is guaranteeing to do this straight after integration.
It sounds like it is up for deferral if time runs out.

The amount of follow-on work that I am hearing about here, and may be for tests, does not  make it sound
like this JEP is nearly as done as first presented.

If there was some expectation that groups responsible for an area would get involved with this
issue which I am assured was already known about, then why was it not raised before and made
part of the plan ?

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

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

From prr at openjdk.java.net  Fri May 21 18:31:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:31:01 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang  wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The client changes are fine except for the one misplaced (c)

test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:

> 1: /*
> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Probably the (c) update was meant to be on the .sh file that is actually modified.

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

Marked as reviewed by prr (Reviewer).

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

From weijun at openjdk.java.net  Fri May 21 19:50:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 19:50:15 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
 <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
Message-ID: 

On Fri, 21 May 2021 18:26:48 GMT, Phil Race  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust order of VM options
>
> test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> Probably the (c) update was meant to be on the .sh file that is actually modified.

Oops, I'll back it out. Thanks.

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

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

From weijun at openjdk.java.net  Fri May 21 20:01:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:01:15 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v3]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

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

  feedback from Phil
  
  reverted:

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/bfa955ad..9a3ec578

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

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

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

From prr at openjdk.java.net  Fri May 21 20:46:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 20:46:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

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

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

From weijun at openjdk.java.net  Fri May 21 20:55:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:55:02 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 20:43:05 GMT, Phil Race  wrote:

> I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
> 
> > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
> 
> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
> > 57:                 ProcessCommunicator
> > 58:                         .executeChildProcess(Consumer.class, new String[0]);
> > 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

I replied right in the thread but unfortunately GitHub does not display it at the end of page.

This is because the process is now launched with `-Djava.security.manager=allow` (because of another change in https://github.com/openjdk/jdk/pull/4071), and a new warning is displayed in stderr. Therefore I switched to stdout.

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

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

From mcimadamore at openjdk.java.net  Fri May 21 23:20:04 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 21 May 2021 23:20:04 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
Message-ID: 

On Fri, 21 May 2021 14:22:47 GMT, Daniel Fuchs  wrote:

>> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
>> 
>> jdk:tier1 and jdk:tier2 are both ok
>
> I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements?
> 
> I am not convinced that a global replacement of  `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient.

I second the footprint concerns from @dfuch. I've seen with first hand cases where widespread uses of array lists for holding 1-2-3 elements (e.g. think of a graph where each node might only have a very small number of outgoing edges) lead to massive memory over-utilization. If the average size is known, at the very least I'd argue to replace with an array list which is sized correctly.

And, all this said, the general assumption implied in this PR which linked lists are just to be avoided doesn't match my experience. If you want a "pay only as much memory as you use" data structure, you don't care about random access (e.g. all accesses are linear walks), a linked list is a perfectly fine choice. If there are use cases in the JDK where a LinkedList is used in places where it shouldn't be, then obviously _those cases_ should be replaced.

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

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

From alanb at openjdk.java.net  Sat May 22 07:00:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 07:00:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 
 
 
Message-ID: 

On Fri, 21 May 2021 18:00:13 GMT, Phil Race  wrote:

> Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
> It is very straight forward to run the automated tests across all platforms these days.
> I get the impression that no one is guaranteeing to do this straight after integration.
> It sounds like it is up for deferral if time runs out.
> 
> The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound
> like this JEP is nearly as done as first presented.
> 
> If there was some expectation that groups responsible for an area would get involved with this
> issue which I am assured was already known about, then why was it not raised before and made
> part of the plan ?

Sprinkling SuppressWarnings should be very low risk. Refactoring code to have the scope of the SW be as small as possible may be a bit more risky, esp. in areas where one doesn't know the code or the tests that exercise it. The tests may be good but it's not clear to me that we want to force Max to do significant refactoring in this PR.  PR 4138 has been created as the follow-on PR so I think we should help get that reviewed so that it can be integrated soon after this PR.

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

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

From mullan at openjdk.java.net  Sun May 23 16:40:59 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Sun, 23 May 2021 16:40:59 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
> 
>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>> 103:  * {@systemProperty java.security.manager} system property is set to the
>> 104:  * special token "{@code allow}", then a security manager will not be set at
> 
> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, I would just keep the first one. (I think it's ok to have more than one, if they are defined in different APIs).

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 07:04:05 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 07:04:05 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
Message-ID: 

On Fri, 21 May 2021 14:15:53 GMT, Daniel Fuchs  wrote:

>> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
>> 
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 155:
> 
>> 153:      */
>> 154:     public List get(String fileName) {
>> 155:         ArrayList jarFiles;
> 
> This could probably be declared as:
> 
> 
> List jarFiles;

Done

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 07:10:40 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 07:10:40 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
Message-ID: 

On Fri, 21 May 2021 14:18:16 GMT, Daniel Fuchs  wrote:

>> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
>> 
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 264:
> 
>> 262:                 String jar = jarFiles[i];
>> 263:                 bw.write(jar + "\n");
>> 264:                 ArrayList jarlist = jarMap.get(jar);
> 
> Here again, jarList could probably be declared as `List`

Done

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 07:17:08 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 07:17:08 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
 
 
Message-ID: 

On Fri, 21 May 2021 15:12:20 GMT, Thiago Henrique H?pner  wrote:

>>> IcedTea-Web seems to be using this method reflectively:
>>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
>> 
>> I assume this doesn't work with JDK 16, at least not without using --add-exports to export jdk.internal.util.jar.
>
> Just for completeness, they're using the add-exports:
> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19

Should we then revert the changes to `JarIndex`?

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

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

From github.com+7806504+liach at openjdk.java.net  Mon May 24 09:28:15 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Mon, 24 May 2021 09:28:15 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
 
 
 
Message-ID: 

On Mon, 24 May 2021 07:13:29 GMT, ?????? ???????  wrote:

>> Just for completeness, they're using the add-exports:
>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19
>
> Should we then revert the changes to `JarIndex`?

But don't people access these internal code at their own risk, as jdk may change these code at any time without notice?

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 10:17:19 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 10:17:19 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
 
 
 
 
Message-ID: 

On Mon, 24 May 2021 09:25:08 GMT, liach  wrote:

>> Should we then revert the changes to `JarIndex`?
>
> But don't people access these internal code at their own risk, as jdk may change these code at any time without notice?

True, I just wonder whether it's OK to change internals when we know for sure that this breaks 3rd party code

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

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

From github.com+7806504+liach at openjdk.java.net  Mon May 24 12:11:38 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Mon, 24 May 2021 12:11:38 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
 
 
 
 
 
Message-ID: 

On Mon, 24 May 2021 10:13:55 GMT, ?????? ???????  wrote:

>> But don't people access these internal code at their own risk, as jdk may change these code at any time without notice?
>
> True, I just wonder whether it's OK to change internals when we know for sure that this breaks 3rd party code

I think so. There are always unexpected ways the jdk may break and third-party libraries would need a different workaround for a new java version. For instance, in Apache log4j, its library has a special guard against the broken implementation of Reflection getCallerClass during java 7. The libraries can just handle these in their version-specific components.

Especially given the fact that the code linked above already has version-specific handling (8 vs 9), so it won't hurt much for them to add another piece of logic to handle jdk 17+ in case this optimization is merged.

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

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

From weijun at openjdk.java.net  Mon May 24 13:53:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

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

  keep only one systemProperty tag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/c4221b5f..1f6ff6c4

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

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

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

From weijun at openjdk.java.net  Mon May 24 13:53:37 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:37 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: 

On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan  wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
>> 
>>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>>> 103:  * {@systemProperty java.security.manager} system property is set to the
>>> 104:  * special token "{@code allow}", then a security manager will not be set at
>> 
>> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.
>
> Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, so we should remove those too.

New commit pushed. There is only one `@systemProperty` tag now.

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

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

From weijun at openjdk.java.net  Mon May 24 14:05:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 14:05:08 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v4]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang 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 20 additional commits since the last revision:

 - Merge branch 'master' into 8267184
 - feedback from Phil
   
   reverted:
 - adjust order of VM options
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/37f74de7...412264a0

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/9a3ec578..412264a0

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

  Stats: 12227 lines in 453 files changed: 6978 ins; 3721 del; 1528 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

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

From weijun at openjdk.java.net  Mon May 24 17:02:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 17:02:13 GMT
Subject: Integrated: 8267184: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <3rH0Qzq38uj4gzgkoDyLE_SnE47c8710ZvGAeSK6UA4=.e080d8bc-838b-4d62-87ff-ca8b12445c8a@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

This pull request has now been integrated.

Changeset: 640a2afd
Author:    Weijun Wang 
URL:       https://git.openjdk.java.net/jdk/commit/640a2afda36857410b7abf398af81e35430a62e7
Stats:     1028 lines in 852 files changed: 252 ins; 9 del; 767 mod

8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

Co-authored-by: Lance Andersen 
Co-authored-by: Weijun Wang 
Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr

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

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

From yyang at openjdk.java.net  Tue May 25 02:12:03 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 25 May 2021 02:12:03 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov  wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   better check1-4
>
> Looks like now the test fails in the pre-submit tests?

Hi @veresov, may?I?ask?your?help?to?review?this?patch??Thanks?a?lot.

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

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

From iveresov at openjdk.java.net  Tue May 25 02:28:01 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 25 May 2021 02:28:01 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 8 May 2021 03:00:14 GMT, Yi Yang  wrote:

>> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.
>> 
>> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.
>> 
>> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:
>> 
>> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
>> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag
>> 
>> Testing: cds, compiler and jdk
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   x86_32 fails

Marked as reviewed by iveresov (Reviewer).

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

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

From yyang at openjdk.java.net  Tue May 25 02:48:06 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 25 May 2021 02:48:06 GMT
Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex
 [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov  wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   better check1-4
>
> Looks like now the test fails in the pre-submit tests?

Thank you @veresov! 

I'm glad to have more comments from hotspot-compiler group.

Later, I'd like to integrate it if there are no more comments/objections.

Thanks!
Yang

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Tue May 25 07:45:32 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 25 May 2021 07:45:32 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v2]
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: 

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

?????? ??????? has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:

 - 8263561: Use interface List instead of particular type where possible
 - 8263561: Rename requestList -> requests
 - 8263561: Re-examine uses of LinkedList

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2744/files
  - new: https://git.openjdk.java.net/jdk/pull/2744/files/73029fe1..158006c6

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

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Tue May 25 11:42:41 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 25 May 2021 11:42:41 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v2]
In-Reply-To: 
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 23:16:57 GMT, Maurizio Cimadamore  wrote:

>> I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements?
>> 
>> I am not convinced that a global replacement of  `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient.
>
> I second the footprint concerns from @dfuch. I've seen with first hand cases where widespread uses of array lists for holding 1-2-3 elements (e.g. think of a graph where each node might only have a very small number of outgoing edges) lead to massive memory over-utilization. If the average size is known, at the very least I'd argue to replace with an array list which is sized correctly.
> 
> And, all this said, the general assumption implied in this PR which linked lists are just to be avoided doesn't match my experience. If you want a "pay only as much memory as you use" data structure, you don't care about random access (e.g. all accesses are linear walks), a linked list is a perfectly fine choice. If there are use cases in the JDK where a LinkedList is used in places where it shouldn't be, then obviously _those cases_ should be replaced.

Hi @mcimadamore, @dfuch after your review comments I've decided to do a deeper investigation for this. First, I've decided to check whether empty `LinkedList` is going to have smaller footprint (this could be fruitful for cases when the list is likely to remain empty in vast majority of cases, see e.g. `URLClassPath.closeLoaders()`), and apparently it isn't:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class EmptyListBenchmark {
    @Benchmark
    public Object emptyArrayList() { return new ArrayList<>(); }

    @Benchmark
    public Object emptyLinkedList() { return new LinkedList<>(); }
}

This benchmark with my ad-hoc JDK build yields the following results:

Benchmark                                                            Mode  Cnt     Score     Error   Units
EmptyListBenchmark.emptyArrayList                                    avgt   20     4.605 ?   0.463   ns/op
EmptyListBenchmark.emptyArrayList:?gc.alloc.rate.norm                avgt   20    24.002 ?   0.001    B/op
EmptyListBenchmark.emptyLinkedList                                   avgt   20     4.324 ?   0.081   ns/op
EmptyListBenchmark.emptyLinkedList:?gc.alloc.rate.norm               avgt   20    32.002 ?   0.001    B/op

After JDK-8011200 `ArrayList` instantiated with default constructor doesn't allocate underlying array any more.

However the things get more complicated when the list gets populated:

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class NonEmptyListBenchmark {
    @Param({"1", "2", "3", "4", "5"})
    private int size;

    @Benchmark
    public Object arrayList() {
        var list = new ArrayList<>();
        for (int i = 0; i < size; i++) {
            list.add(i);
        }
        return list;
    }

    @Benchmark
    public Object linkedList() {
        var list = new LinkedList();
        for (int i = 0; i < size; i++) {
            list.add(i);
        }
        return list;
    }
}

Here indeed `ArrayList` looses in memory comapring to `LinkedList` in single-item case:

arrayList:?gc.alloc.rate.norm                       1  avgt   40    80.005 ?   0.001    B/op
arrayList:?gc.alloc.rate.norm                       2  avgt   40    80.006 ?   0.001    B/op
arrayList:?gc.alloc.rate.norm                       3  avgt   40    80.007 ?   0.001    B/op
arrayList:?gc.alloc.rate.norm                       4  avgt   40    80.008 ?   0.001    B/op
arrayList:?gc.alloc.rate.norm                       5  avgt   40    80.008 ?   0.001    B/op

linkedList:?gc.alloc.rate.norm                      1  avgt   40    56.004 ?   0.001    B/op
linkedList:?gc.alloc.rate.norm                      2  avgt   40    80.005 ?   0.001    B/op
linkedList:?gc.alloc.rate.norm                      3  avgt   40   104.007 ?   0.001    B/op
linkedList:?gc.alloc.rate.norm                      4  avgt   40   128.009 ?   0.001    B/op
linkedList:?gc.alloc.rate.norm                      5  avgt   40   152.010 ?   0.001    B/op

And indeed there's at least one usecase in affected files where this is real-life scenario - `JarIndex`. Below on screenshot I run Spring Boot tests with Gradle:

![image](https://d.radikal.ru/d26/2105/d0/a5d588f282e6.png)

However, for the same scenario one node represented with `LinkedList` can hold dozens of items:

![image](https://c.radikal.ru/c38/2105/da/80e6a78cec08.png)

To fix this I propose to instantiate `ArrayList` with initial size = 1:

@Benchmark
public Object arrayList_sized() {
  var list = new ArrayList<>(1);
  list.add(new Object());
  return list;
}

This reduces the footprint of a list with 1 element down to 48 bytes:

arrayList_sized:?gc.alloc.rate.norm                      1  avgt   40    48.004 ?   0.001    B/op

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Tue May 25 12:03:29 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 25 May 2021 12:03:29 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v3]
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: 

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

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

  8263561: Use sized constructor where reasonable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2744/files
  - new: https://git.openjdk.java.net/jdk/pull/2744/files/158006c6..40910fae

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

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Tue May 25 13:44:14 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 25 May 2021 13:44:14 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v4]
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <8QDoLOsBNG7VYDd7ryDVkNTHt9Z-T9QeZ2ll0bWGonQ=.0335a58a-744f-4acc-a226-6c3abbc14914@github.com>

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

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

 - Merge branch 'master' into purge-linked-list
 - 8263561: Use sized constructor where reasonable
 - 8263561: Use interface List instead of particular type where possible
 - 8263561: Rename requestList -> requests
 - 8263561: Re-examine uses of LinkedList

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2744/files
  - new: https://git.openjdk.java.net/jdk/pull/2744/files/40910fae..89160b3e

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

  Stats: 763526 lines in 11131 files changed: 166175 ins; 560683 del; 36668 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2744.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744

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

From mcimadamore at openjdk.java.net  Thu May 27 10:11:43 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 27 May 2021 10:11:43 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v25]
In-Reply-To: 
References: 
Message-ID: 

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

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

  * Add missing `final` in some static fields
  * Downgrade native methods in ProgrammableUpcallHandler to package-private

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/e927c235..e1fcd2d3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=23-24

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

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

From mcimadamore at openjdk.java.net  Thu May 27 10:37:38 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 27 May 2021 10:37:38 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v26]
In-Reply-To: 
References: 
Message-ID: <9sO-moMQsSpzVGkmQ50SQAS1dcBNpC0EyO83lwDGFNI=.a4c737f0-7d4f-43a7-a5f8-2a504b20690f@github.com>

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

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

 - Merge branch 'master' into JEP-412
 - * Add missing `final` in some static fields
   * Downgrade native methods in ProgrammableUpcallHandler to package-private
 - Add sealed modifiers in morally sealed API interfaces
 - Merge branch 'master' into JEP-412
 - Fix VaList test
   Remove unused code in Utils
 - Merge pull request #11 from JornVernee/JEP-412-MXCSR
   
   Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Merge branch 'master' into JEP-412
 - Fix issue with bounded arena allocator
 - Rename is_entry_blob to is_optimized_entry_blob
   Rename as_entry_blob to as_optimized_entry_blob
   Fix misc typos and indentation issues
 - ... and 27 more: https://git.openjdk.java.net/jdk/compare/7278f56b...8bbddfc2

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

Changes: https://git.openjdk.java.net/jdk/pull/3699/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=25
  Stats: 14501 lines in 219 files changed: 8847 ins; 3642 del; 2012 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

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

From prr at openjdk.java.net  Thu May 27 17:15:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 17:15:06 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep only one systemProperty tag

Marked as reviewed by prr (Reviewer).

I'm OK with this now given that the refactoring is already underway at https://github.com/openjdk/jdk/pull/4138

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

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

From bpb at openjdk.java.net  Thu May 27 19:37:10 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 27 May 2021 19:37:10 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 12 Mar 2021 21:33:18 GMT, Brian Burkhalter  wrote:

>> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`.
>> 
>> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.)
>> 
>> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension.
>> 
>> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero.
>> 
>> The behavior of the proposed method for some example cases is as:
>> 
>> 
>> .              -> 
>> ..             -> 
>> .a.b           -> b
>> ......         -> 
>> .....a         -> a
>> ....a.b        -> b
>> ..foo          -> foo
>> test.rb        -> rb
>> a/b/d/test.rb  -> rb
>> .a/b/d/test.rb -> rb
>> foo.           -> 
>> test           -> 
>> .profile       -> 
>> .profile.sh    -> sh
>> ..foo          -> foo
>> .....foo       -> foo
>> .vimrc         -> 
>> test.          -> 
>> test..         -> 
>> test...        -> 
>> foo.tar.gz     -> gz
>> foo.bar.       -> 
>> image.jpg      -> jpg
>> music.mp3      -> mp3
>> video.mp4      -> mp4
>> document.txt   -> txt
>> foo.tar.gz     -> gz
>> foo.bar.       ->
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8057113: Change first sentence; change param name

PR extension.

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

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

From weijun at openjdk.java.net  Thu May 27 20:16:25 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 27 May 2021 20:16:25 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

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

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04
  Stats: 2022 lines in 825 files changed: 1884 ins; 10 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

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

From weijun at openjdk.java.net  Fri May 28 02:01:19 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 02:01:19 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Thu, 27 May 2021 20:16:25 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Two files were removed by JEP 403 and JEP 407, respectively. One method in `XMLSchemaFactory.java` got [its own](https://github.com/openjdk/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2#diff-593a224979eaff03e2a3df1863fcaf865364a31a2212cc0d1fe67a8458057857R429) `@SuppressWarnings` and have to be merged with the one here. Another file `ResourceBundle.java` had a portion of a method extracted into a [new method](https://github.com/openjdk/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424#diff-59caf1a68085064b4b3eb4f6e33e440bb85ea93719f34660970e2d4eaf8ce469R3175) and the annotation must be moved there.

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

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

From weijun at openjdk.java.net  Mon May 31 15:02:57 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:02:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

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

  default behavior reverted to allow

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/01dc4c0d..8fd09c39

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

  Stats: 183 lines in 6 files changed: 127 ins; 23 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

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

From weijun at openjdk.java.net  Mon May 31 15:09:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:09:27 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: 

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

New commit pushed. The default behavior is now reverted to be equivalent to `-Djava.security.manager=allow`. No warning will be shown when the system property is set to "allow", "disallow", or not set. A new test is added to check these warning messages. Some tests are updated to match the new behavior.

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

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

From lancea at openjdk.java.net  Mon May 31 16:24:24 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 31 May 2021 16:24:24 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <95Pzw60HuW83TYfd9Dogs6AdG0GDq0Ajh8McoTvRhJU=.37e0db8a-8670-408f-81cd-b5d30ea724ce@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

Marked as reviewed by lancea (Reviewer).

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

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