From djelinski at openjdk.org Mon Jan 2 08:14:53 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 2 Jan 2023 08:14:53 GMT Subject: RFR: 6914801: IPv6 unavailable if stdin is a socket In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 20:30:05 GMT, Daniel Jeli?ski wrote: > This patch reenables IPv6 stack when stdin is an IPv4 socket. > > The code that blocked IPv6 was introduced in JDK-4673940 back when JDK could only operate with either IPv4 or IPv6 sockets, and was using `IPv6_available` to determine which socket type was in use. Now that JDK is able to operate with both IPv4 and IPv6 sockets at the same time, the check for IPv4 stdin is no longer relevant. > > Included test passes with the changes applied, fails without them. Other tier1-3 tests also pass. Happy new year! Thanks Alan for checking this. Can I get a more formal review? The test I added is basically a copy of EchoTest, except that 1) it runs only if an IPv6 socket can be opened by the harness, 2) the started application works only if it can open an IPv6 socket. I also modified the tests to use IPv4 sockets for communication when they are available. If IPv4 is not available, the test will use platform-default socket type, and should still pass. ------------- PR: https://git.openjdk.org/jdk/pull/11638 From pminborg at openjdk.org Mon Jan 2 08:17:17 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 2 Jan 2023 08:17:17 GMT Subject: RFR: 8299187: Ensure safe publication of name in ByteOrder [v2] In-Reply-To: References: Message-ID: > This PR proposes to declare the field `ByteOrder.name` `final`. > > This will ensure the class is thread safe and is using safe publication. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11752/files - new: https://git.openjdk.org/jdk/pull/11752/files/67630460..1747b2dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11752&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11752&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11752.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11752/head:pull/11752 PR: https://git.openjdk.org/jdk/pull/11752 From jpai at openjdk.org Mon Jan 2 09:03:49 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 2 Jan 2023 09:03:49 GMT Subject: RFR: 8299193: Declare Buffer.capacity final In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 12:22:33 GMT, Per Minborg wrote: > It is possible to declare the field `capacity` in `java.nio.Buffer` `final` as the value never changes outside the constructors. Hello Per, this and the other similar PR will need their PR title to be updated to match their latest JBS issue summaries. ------------- PR: https://git.openjdk.org/jdk/pull/11755 From pminborg at openjdk.org Mon Jan 2 09:07:01 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 2 Jan 2023 09:07:01 GMT Subject: RFR: 8299187: Ensure safe publication of name in ByteOrder [v3] In-Reply-To: References: Message-ID: > This PR proposes to declare the field `ByteOrder.name` `final`. > > This will ensure the class is thread safe and is using safe publication. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11752/files - new: https://git.openjdk.org/jdk/pull/11752/files/1747b2dc..8d20839d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11752&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11752&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11752.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11752/head:pull/11752 PR: https://git.openjdk.org/jdk/pull/11752 From jpai at openjdk.org Mon Jan 2 09:07:05 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 2 Jan 2023 09:07:05 GMT Subject: RFR: 8299187: Ensure safe publication of name in ByteOrder [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 08:17:17 GMT, Per Minborg wrote: >> This PR proposes to declare the field `ByteOrder.name` `final`. >> >> This will ensure the class is thread safe and is using safe publication. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year src/java.base/share/classes/java/nio/ByteOrder.java line 2: > 1: /* > 2: * Copyright (c) 2000, 2023 Oracle and/or its affiliates. All rights reserved. Hello Per, a comma is required after `2023`. ------------- PR: https://git.openjdk.org/jdk/pull/11752 From jpai at openjdk.org Mon Jan 2 09:14:49 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 2 Jan 2023 09:14:49 GMT Subject: RFR: 8299187: Ensure safe publication of name in ByteOrder [v3] In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 09:07:01 GMT, Per Minborg wrote: >> This PR proposes to declare the field `ByteOrder.name` `final`. >> >> This will ensure the class is thread safe and is using safe publication. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11752 From pminborg at openjdk.org Mon Jan 2 13:26:05 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 2 Jan 2023 13:26:05 GMT Subject: Integrated: 8299187: (bf) ByteOrder.name should be declared final In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 09:29:59 GMT, Per Minborg wrote: > This PR proposes to declare the field `ByteOrder.name` `final`. > > This will ensure the class is thread safe and is using safe publication. This pull request has now been integrated. Changeset: e09e2431 Author: Per Minborg Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/e09e243116545a7c1324bfcc145c94fbc25c7d59 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8299187: (bf) ByteOrder.name should be declared final Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/11752 From pminborg at openjdk.org Mon Jan 2 13:28:56 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 2 Jan 2023 13:28:56 GMT Subject: Integrated: 8299193: (bf) Buffer.capacity should be declared final In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 12:22:33 GMT, Per Minborg wrote: > It is possible to declare the field `capacity` in `java.nio.Buffer` `final` as the value never changes outside the constructors. This pull request has now been integrated. Changeset: 8a10eef4 Author: Per Minborg Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/8a10eef408f10d1a6d698a6f74942111b72d0765 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8299193: (bf) Buffer.capacity should be declared final Reviewed-by: rriggs, dholmes, jpai ------------- PR: https://git.openjdk.org/jdk/pull/11755 From mbaesken at openjdk.org Mon Jan 2 16:23:32 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 2 Jan 2023 16:23:32 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area Message-ID: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. ------------- Commit messages: - JDK-8299475 Changes: https://git.openjdk.org/jdk/pull/11813/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11813&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299475 Stats: 13 lines in 4 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/11813.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11813/head:pull/11813 PR: https://git.openjdk.org/jdk/pull/11813 From alanb at openjdk.org Mon Jan 2 16:37:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 2 Jan 2023 16:37:49 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area In-Reply-To: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: <9VCHk3nkgtduGeyeawEF-WHEpojzEKLzmAK-5_9-kU0=.c115e4d5-dc23-4ea2-ad26-b369f0138a27@github.com> On Mon, 2 Jan 2023 16:16:08 GMT, Matthias Baesken wrote: > We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. src/java.base/share/classes/java/net/ServerSocket.java line 697: > 695: if (thread.isVirtual() && thread.isInterrupted()) { > 696: close(); > 697: throw new SocketException("Closed by interrupt", e); The InterruptedIOException is used by the SocketImpl to communicate the interrupt to the ServerSocket. It should not be added a cause here. Same thing in the Socket code. src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 313: > 311: } catch (ConnectionResetException e) { > 312: connectionReset = true; > 313: throw new SocketException("Connection reset", e); This is internal exception and should not be added as a cause here. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From alanb at openjdk.org Mon Jan 2 16:56:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 2 Jan 2023 16:56:50 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area In-Reply-To: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: On Mon, 2 Jan 2023 16:16:08 GMT, Matthias Baesken wrote: > We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. src/java.base/share/classes/java/net/ServerSocket.java line 302: > 300: throw e; > 301: } catch (IOException e) { > 302: throw new SocketException(e.getMessage(), e); This one is probably okay although most of the stack trace of the cause will be identical to that of the SocketException so it might be confusing in logs. The equivalent in Socket might be a bit more useful as there are several SocketImpls used for client sockets. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Tue Jan 3 08:29:13 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Jan 2023 08:29:13 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v2] In-Reply-To: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: > We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: do not enhance some internal exceptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11813/files - new: https://git.openjdk.org/jdk/pull/11813/files/b8933007..5c4c58c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11813&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11813&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11813.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11813/head:pull/11813 PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Tue Jan 3 08:29:14 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Jan 2023 08:29:14 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v2] In-Reply-To: <9VCHk3nkgtduGeyeawEF-WHEpojzEKLzmAK-5_9-kU0=.c115e4d5-dc23-4ea2-ad26-b369f0138a27@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> <9VCHk3nkgtduGeyeawEF-WHEpojzEKLzmAK-5_9-kU0=.c115e4d5-dc23-4ea2-ad26-b369f0138a27@github.com> Message-ID: On Mon, 2 Jan 2023 16:34:26 GMT, Alan Bateman wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> do not enhance some internal exceptions > > src/java.base/share/classes/java/net/ServerSocket.java line 697: > >> 695: if (thread.isVirtual() && thread.isInterrupted()) { >> 696: close(); >> 697: throw new SocketException("Closed by interrupt", e); > > The InterruptedIOException is used by the SocketImpl to communicate the interrupt to the ServerSocket. It should not be added a cause here. Same thing in the Socket code. Hi Alan, I removed this one. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Tue Jan 3 08:32:49 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Jan 2023 08:32:49 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v2] In-Reply-To: References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: On Tue, 3 Jan 2023 08:29:13 GMT, Matthias Baesken wrote: >> We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > do not enhance some internal exceptions Hi Alan, I removed the InterruptedIOException enhancement . Regarding the ConnectionResetException in NioSocketImpl.java, it is not so bad to know what tryRead caused it. So why not add it ? Additionally we could also add the errno (EPIPE or ECONNRESET) to the exception message to get a better picture of the error situation (see java.base/unix/native/libnio/ch/SocketDispatcher.c ). ------------- PR: https://git.openjdk.org/jdk/pull/11813 From alanb at openjdk.org Tue Jan 3 08:49:48 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Jan 2023 08:49:48 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v2] In-Reply-To: References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: <33d0KGFguWmBDc_rc4XUZ-El_5BjSCg7la9uKUlUe8A=.d4acb899-07a5-4786-bb4e-9b3f200ce76a@github.com> On Tue, 3 Jan 2023 08:29:41 GMT, Matthias Baesken wrote: > Hi Alan, I removed the InterruptedIOException enhancement . Regarding the ConnectionResetException in NioSocketImpl.java, it is not so bad to know what tryRead caused it. So why not add it ? > > Additionally we could also add the errno (EPIPE or ECONNRESET) to the exception message to get a better picture of the error situation (see java.base/unix/native/libnio/ch/SocketDispatcher.c ). sun.net.ConnectionResetException is used to communicate the error from the native code to the socket impl. It's part of an internal contract and never ended to be leak out to user code. There have been discussions every few yers about introducing a specific SocketException for the "connection reset" scenario and maybe it is time to look at that again. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Tue Jan 3 08:49:49 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Jan 2023 08:49:49 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v2] In-Reply-To: <33d0KGFguWmBDc_rc4XUZ-El_5BjSCg7la9uKUlUe8A=.d4acb899-07a5-4786-bb4e-9b3f200ce76a@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> <33d0KGFguWmBDc_rc4XUZ-El_5BjSCg7la9uKUlUe8A=.d4acb899-07a5-4786-bb4e-9b3f200ce76a@github.com> Message-ID: <9wo0tPZiqusi_3nWX7UiaM1rXvmw7FdUKOhaJOHKTtI=.36aaa679-5089-4540-bac9-3119866de474@github.com> On Tue, 3 Jan 2023 08:43:04 GMT, Alan Bateman wrote: > > Hi Alan, I removed the InterruptedIOException enhancement . Regarding the ConnectionResetException in NioSocketImpl.java, it is not so bad to know what tryRead caused it. So why not add it ? > > Additionally we could also add the errno (EPIPE or ECONNRESET) to the exception message to get a better picture of the error situation (see java.base/unix/native/libnio/ch/SocketDispatcher.c ). > > sun.net.ConnectionResetException is used to communicate the error from the native code to the socket impl. It's part of an internal contract and never ended to be leak out to user code. > > There have been discussions every few yers about introducing a specific SocketException for the "connection reset" scenario and maybe it is time to look at that again. Hi Alan, do you mean some new class like java/net/SocketConnectionResetException.java (or a more suitable name) ? ------------- PR: https://git.openjdk.org/jdk/pull/11813 From alanb at openjdk.org Tue Jan 3 08:49:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Jan 2023 08:49:52 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v2] In-Reply-To: References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: On Tue, 3 Jan 2023 08:29:13 GMT, Matthias Baesken wrote: >> We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > do not enhance some internal exceptions src/java.base/share/classes/java/net/Socket.java line 535: > 533: created = true; > 534: } catch (IOException e) { > 535: throw new SocketException(e.getMessage(), e); For this one, you could `catch (SocketException e) { throw e; }` as the exception from the impl will be a SocketException anyway. That would help avoid the confusing cause. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Tue Jan 3 08:52:48 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Jan 2023 08:52:48 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v2] In-Reply-To: References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: On Tue, 3 Jan 2023 08:45:11 GMT, Alan Bateman wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> do not enhance some internal exceptions > > src/java.base/share/classes/java/net/Socket.java line 535: > >> 533: created = true; >> 534: } catch (IOException e) { >> 535: throw new SocketException(e.getMessage(), e); > > For this one, you could `catch (SocketException e) { throw e; }` as the exception from the impl will be a SocketException anyway. That would help avoid the confusing cause. Hi Alan, createImpl throws SocketException anyway, so can't we just remove the catch completely in this case ? Or are there other IOExceptions? ------------- PR: https://git.openjdk.org/jdk/pull/11813 From alanb at openjdk.org Tue Jan 3 09:18:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Jan 2023 09:18:49 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v2] In-Reply-To: <9wo0tPZiqusi_3nWX7UiaM1rXvmw7FdUKOhaJOHKTtI=.36aaa679-5089-4540-bac9-3119866de474@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> <33d0KGFguWmBDc_rc4XUZ-El_5BjSCg7la9uKUlUe8A=.d4acb899-07a5-4786-bb4e-9b3f200ce76a@github.com> <9wo0tPZiqusi_3nWX7UiaM1rXvmw7FdUKOhaJOHKTtI=.36aaa679-5089-4540-bac9-3119866de474@github.com> Message-ID: On Tue, 3 Jan 2023 08:47:24 GMT, Matthias Baesken wrote: > Hi Alan, do you mean some new class like java/net/SocketConnectionResetException.java (or a more suitable name) ? Yes, although we never managed to come up to agreement on whether to introduce a standard exception. For now, it is important to not leak the internal exception - that is there solely as an internal contract. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From alanb at openjdk.org Tue Jan 3 09:18:51 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Jan 2023 09:18:51 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v2] In-Reply-To: References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: <-prXUhEkBRGTgAY6en6NgIvsR88jcYO7h-sX_3PQyCE=.15eab4ba-7ca2-4304-84b6-2248cd7658f4@github.com> On Tue, 3 Jan 2023 08:50:10 GMT, Matthias Baesken wrote: >> src/java.base/share/classes/java/net/Socket.java line 535: >> >>> 533: created = true; >>> 534: } catch (IOException e) { >>> 535: throw new SocketException(e.getMessage(), e); >> >> For this one, you could `catch (SocketException e) { throw e; }` as the exception from the impl will be a SocketException anyway. That would help avoid the confusing cause. > > Hi Alan, createImpl throws SocketException anyway, so can't we just remove the catch completely in this case ? > Or are there other IOExceptions? Our SocketImpls mostly throw SocketException so inserting the catch of SocketException will avoid the translation for most cases. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Tue Jan 3 10:27:48 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Jan 2023 10:27:48 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v2] In-Reply-To: <-prXUhEkBRGTgAY6en6NgIvsR88jcYO7h-sX_3PQyCE=.15eab4ba-7ca2-4304-84b6-2248cd7658f4@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> <-prXUhEkBRGTgAY6en6NgIvsR88jcYO7h-sX_3PQyCE=.15eab4ba-7ca2-4304-84b6-2248cd7658f4@github.com> Message-ID: <-C1DFKb_LTBpBjK8ss91yCGKxyjpEORuo5AOsabDAYg=.bef9cebe-0e24-4803-9cea-d454f4528a3f@github.com> On Tue, 3 Jan 2023 09:14:11 GMT, Alan Bateman wrote: >> Hi Alan, createImpl throws SocketException anyway, so can't we just remove the catch completely in this case ? >> Or are there other IOExceptions? > > Our SocketImpls mostly throw SocketException so inserting the catch of SocketException will avoid the translation for most cases. Replacing the IOException does not work, this even leads to a compile error " unreported exception IOException" ; so I guess the catch (SocketException e) needs to be added to the IOException ; not so nice. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From alanb at openjdk.org Tue Jan 3 10:31:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Jan 2023 10:31:49 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v2] In-Reply-To: <-C1DFKb_LTBpBjK8ss91yCGKxyjpEORuo5AOsabDAYg=.bef9cebe-0e24-4803-9cea-d454f4528a3f@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> <-prXUhEkBRGTgAY6en6NgIvsR88jcYO7h-sX_3PQyCE=.15eab4ba-7ca2-4304-84b6-2248cd7658f4@github.com> <-C1DFKb_LTBpBjK8ss91yCGKxyjpEORuo5AOsabDAYg=.bef9cebe-0e24-4803-9cea-d454f4528a3f@github.com> Message-ID: On Tue, 3 Jan 2023 10:25:21 GMT, Matthias Baesken wrote: >> Our SocketImpls mostly throw SocketException so inserting the catch of SocketException will avoid the translation for most cases. > > Replacing the IOException does not work, this even leads to a compile error " unreported exception IOException" ; so I guess the catch (SocketException e) needs to be added to the IOException ; not so nice. I didn't mean to replace it, I meant to insert of catch of SocketException before the IOException. That will avoid throwing SocketException with cause SocketException. If you look at the equivalent in ServerSocket then you'll see what I mean. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Tue Jan 3 10:47:11 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Jan 2023 10:47:11 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v3] In-Reply-To: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: > We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: re-throw SocketException, remove one enhancement because it is meant to be internal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11813/files - new: https://git.openjdk.org/jdk/pull/11813/files/5c4c58c3..4eb84f37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11813&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11813&range=01-02 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11813.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11813/head:pull/11813 PR: https://git.openjdk.org/jdk/pull/11813 From michaelm at openjdk.org Tue Jan 3 12:38:52 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 3 Jan 2023 12:38:52 GMT Subject: RFR: 6914801: IPv6 unavailable if stdin is a socket In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 08:11:39 GMT, Daniel Jeli?ski wrote: > Happy new year! Thanks Alan for checking this. Can I get a more formal review? > > The test I added is basically a copy of EchoTest, except that 1) it runs only if an IPv6 socket can be opened by the harness, 2) the started application works only if it can open an IPv6 socket. I also modified the tests to use IPv4 sockets for communication when they are available. If IPv4 is not available, the test will use platform-default socket type, and should still pass. Checking it now. ------------- PR: https://git.openjdk.org/jdk/pull/11638 From alanb at openjdk.org Tue Jan 3 13:48:51 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Jan 2023 13:48:51 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v3] In-Reply-To: References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: <-JJb5gUUjle7DgCqjXuPm9h6hnCWHMEBm6VlrYbihzs=.edb76d2e-c31f-48db-97cb-0671bd4e1eae@github.com> On Tue, 3 Jan 2023 10:47:11 GMT, Matthias Baesken wrote: >> We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > re-throw SocketException, remove one enhancement because it is meant to be internal src/java.base/share/classes/java/net/Socket.java line 537: > 535: throw e; > 536: } catch (IOException e) { > 537: throw new SocketException(e.getMessage()); I can't immediately think of real cases where a non-SocketException is thrown when creating a SocketImpl but for consistency with the equivalent in ServerSocket then you could add the cause here too. src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 413: > 411: throw e; > 412: } catch (IOException ioe) { > 413: throw new SocketException(ioe.getMessage(), ioe); I'm in two minds on whether this is a good idea or not because the stack trace of the cause is mostly the same as the SocketException, e.g. right now we get a clear stack trace like this: Exception in thread "main" java.net.SocketException: Broken pipe at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:413) at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:433) at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:812) at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1192) at java.base/java.io.OutputStream.write(OutputStream.java:124) but with the change we get a cause with almost the same stack trace: Exception in thread "main" java.net.SocketException: Broken pipe at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:413) at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:433) at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:812) at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1192) at java.base/java.io.OutputStream.write(OutputStream.java:124) Caused by: java.io.IOException: Broken pipe at java.base/sun.nio.ch.SocketDispatcher.write0(Native Method) at java.base/sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:62) at java.base/sun.nio.ch.NioSocketImpl.tryWrite(NioSocketImpl.java:388) at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:404) at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:433) at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:812) at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1192) at java.base/java.io.OutputStream.write(OutputStream.java:124) The reason for the translation from IOException to SocketException is so that the SocketImpl added via JEP 353 throws the same specific exceptions as the legacy implementation. We were concerned there may be older code assuming that read/write throw SocketException. So one idea here is to avoid the confusing cause is to use the stack trace from the IOException, as in: var e = new SocketException(ioe.getMessage()); e.setStackTrace(ioe.getStackTrace()); throw e; which gives us a clear stack trace like we have now: Exception in thread "main" java.net.SocketException: Broken pipe at java.base/sun.nio.ch.SocketDispatcher.write0(Native Method) at java.base/sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:62) at java.base/sun.nio.ch.NioSocketImpl.tryWrite(NioSocketImpl.java:388) at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:404) at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:435) at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:814) at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1192) at java.base/java.io.OutputStream.write(OutputStream.java:124) ------------- PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Tue Jan 3 13:57:20 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Jan 2023 13:57:20 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v4] In-Reply-To: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: > We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust Socket createImpl again ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11813/files - new: https://git.openjdk.org/jdk/pull/11813/files/4eb84f37..8af8a34d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11813&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11813&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11813.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11813/head:pull/11813 PR: https://git.openjdk.org/jdk/pull/11813 From michaelm at openjdk.org Tue Jan 3 18:29:49 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 3 Jan 2023 18:29:49 GMT Subject: RFR: 6914801: IPv6 unavailable if stdin is a socket In-Reply-To: References: Message-ID: <-WB063qWyxVeQzaciIVXaQRtNPOZRxIQd5b0lUNdZjY=.d07726ef-a3f7-4366-aecb-34c47a78288f@github.com> On Mon, 12 Dec 2022 20:30:05 GMT, Daniel Jeli?ski wrote: > This patch reenables IPv6 stack when stdin is an IPv4 socket. > > The code that blocked IPv6 was introduced in JDK-4673940 back when JDK could only operate with either IPv4 or IPv6 sockets, and was using `IPv6_available` to determine which socket type was in use. Now that JDK is able to operate with both IPv4 and IPv6 sockets at the same time, the check for IPv4 stdin is no longer relevant. > > Included test passes with the changes applied, fails without them. Other tier1-3 tests also pass. test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java line 112: > 110: try (ServerSocketChannel ssc = ch) { > 111: ssc.socket().bind(new InetSocketAddress(InetAddress.getLoopbackAddress(), 0)); > 112: SocketChannel sc1 = SocketChannel.open(ssc.getLocalAddress()); Could we add some logging/printlns here to indicate the protocol family of `ch` or its local address, to aid in debugging if we ever have problems with the test (eg on IPv6 only systems)? ------------- PR: https://git.openjdk.org/jdk/pull/11638 From alanb at openjdk.org Tue Jan 3 20:38:51 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Jan 2023 20:38:51 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v4] In-Reply-To: References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: On Tue, 3 Jan 2023 13:57:20 GMT, Matthias Baesken wrote: >> We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Socket createImpl again The changes in [8af8a34d] to Socket, ServerSocket and SocksSocketImpl looks okay. I think the changes to NioSocketImpl will lead to confusing output as the cause will be almost identify to the SocketException. I assume your goal with the change is to get the deepest implementation frames into the stack trace. They would be there if read/write threw IOException but we decided in JEP 353 to throw the more specific SocketException to maintain historical behavior. So maybe we could try this instead - this will throw the SocketException with the stack trace from the IOException so it will include the deepest frames: diff --git a/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java b/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java index b2531135b03..f96d8380f29 100644 --- a/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java +++ b/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java @@ -312,7 +312,8 @@ public final class NioSocketImpl extends SocketImpl implements PlatformSocketImp connectionReset = true; throw new SocketException("Connection reset"); } catch (IOException ioe) { - throw new SocketException(ioe.getMessage()); + // throw SocketException to maintain compatibility + throw asSocketException(ioe); } finally { endRead(n > 0); } @@ -410,7 +411,8 @@ public final class NioSocketImpl extends SocketImpl implements PlatformSocketImp } catch (InterruptedIOException e) { throw e; } catch (IOException ioe) { - throw new SocketException(ioe.getMessage()); + // throw SocketException to maintain compatibility + throw asSocketException(ioe); } finally { endWrite(n > 0); } @@ -1081,10 +1083,8 @@ public final class NioSocketImpl extends SocketImpl implements PlatformSocketImp default: throw new SocketException("Unknown option " + opt); } - } catch (SocketException e) { - throw e; } catch (IllegalArgumentException | IOException e) { - throw new SocketException(e.getMessage()); + throw asSocketException(e); } } } @@ -1133,10 +1133,8 @@ public final class NioSocketImpl extends SocketImpl implements PlatformSocketImp default: throw new SocketException("Unknown option " + opt); } - } catch (SocketException e) { - throw e; } catch (IllegalArgumentException | IOException e) { - throw new SocketException(e.getMessage()); + throw asSocketException(e); } } } @@ -1249,6 +1247,19 @@ public final class NioSocketImpl extends SocketImpl implements PlatformSocketImp return remainingNanos; } + /** + * Creates a SocketException from the given exception. + */ + private static SocketException asSocketException(Exception e) { + if (e instanceof SocketException se) { + return se; + } else { + var se = new SocketException(e.getMessage()); + se.setStackTrace(e.getStackTrace()); + return se; + } + } + /** * Returns the socket protocol family. */ ------------- PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Wed Jan 4 09:04:06 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 09:04:06 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v3] In-Reply-To: <-JJb5gUUjle7DgCqjXuPm9h6hnCWHMEBm6VlrYbihzs=.edb76d2e-c31f-48db-97cb-0671bd4e1eae@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> <-JJb5gUUjle7DgCqjXuPm9h6hnCWHMEBm6VlrYbihzs=.edb76d2e-c31f-48db-97cb-0671bd4e1eae@github.com> Message-ID: On Tue, 3 Jan 2023 13:45:13 GMT, Alan Bateman wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> re-throw SocketException, remove one enhancement because it is meant to be internal > > src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 413: > >> 411: throw e; >> 412: } catch (IOException ioe) { >> 413: throw new SocketException(ioe.getMessage(), ioe); > > I'm in two minds on whether this is a good idea or not because the stack trace of the cause is mostly the same as the SocketException, e.g. right now we get a clear stack trace like this: > > Exception in thread "main" java.net.SocketException: Broken pipe > at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:413) > at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:433) > at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:812) > at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1192) > at java.base/java.io.OutputStream.write(OutputStream.java:124) > > > but with the change we get a cause with almost the same stack trace: > > Exception in thread "main" java.net.SocketException: Broken pipe > at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:413) > at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:433) > at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:812) > at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1192) > at java.base/java.io.OutputStream.write(OutputStream.java:124) > Caused by: java.io.IOException: Broken pipe > at java.base/sun.nio.ch.SocketDispatcher.write0(Native Method) > at java.base/sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:62) > at java.base/sun.nio.ch.NioSocketImpl.tryWrite(NioSocketImpl.java:388) > at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:404) > at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:433) > at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:812) > at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1192) > at java.base/java.io.OutputStream.write(OutputStream.java:124) > > > The reason for the translation from IOException to SocketException is so that the SocketImpl added via JEP 353 throws the same specific exceptions as the legacy implementation. We were concerned there may be older code assuming that read/write throw SocketException. So one idea here is to avoid the confusing cause is to use the stack trace from the IOException, as in: > > var e = new SocketException(ioe.getMessage()); > e.setStackTrace(ioe.getStackTrace()); > throw e; > > which gives us a clear stack trace like we have now: > > Exception in thread "main" java.net.SocketException: Broken pipe > at java.base/sun.nio.ch.SocketDispatcher.write0(Native Method) > at java.base/sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:62) > at java.base/sun.nio.ch.NioSocketImpl.tryWrite(NioSocketImpl.java:388) > at java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:404) > at java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:435) > at java.base/sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:814) > at java.base/java.net.Socket$SocketOutputStream.write(Socket.java:1192) > at java.base/java.io.OutputStream.write(OutputStream.java:124) Hi Alan, I adjusted this coding following your suggestion to use setStackTrace. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Wed Jan 4 09:04:05 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 09:04:05 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v5] In-Reply-To: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: <07WiH0DJiZjyVoDtlT82cvR-dYzua9awfaAXpwql4MY=.3e8badbb-994b-45f8-a816-c026fe4aa3bf@github.com> > We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: NioSocketImpl shorten extended exception ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11813/files - new: https://git.openjdk.org/jdk/pull/11813/files/8af8a34d..62916a71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11813&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11813&range=03-04 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11813.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11813/head:pull/11813 PR: https://git.openjdk.org/jdk/pull/11813 From alanb at openjdk.org Wed Jan 4 10:03:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 4 Jan 2023 10:03:49 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v3] In-Reply-To: References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> <-JJb5gUUjle7DgCqjXuPm9h6hnCWHMEBm6VlrYbihzs=.edb76d2e-c31f-48db-97cb-0671bd4e1eae@github.com> Message-ID: On Wed, 4 Jan 2023 08:59:51 GMT, Matthias Baesken wrote: > Hi Alan, I adjusted this coding following your suggestion to use setStackTrace. That's just one of them. In a later comment I pasted in asSocketException and changed all 4 cases to use it, maybe you could try that. The right thing is of course to drop the translation to SocketException as anything using read/write has to deal with IOException anyway, it's really just a concern that older code may having special handling of SocketException of undocumented, but longstanding, behavior in older JDK releases. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Wed Jan 4 11:36:13 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 11:36:13 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v6] In-Reply-To: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: > We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Introduce asSocketException in nio ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11813/files - new: https://git.openjdk.org/jdk/pull/11813/files/62916a71..655cf6ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11813&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11813&range=04-05 Stats: 20 lines in 1 file changed: 14 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11813.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11813/head:pull/11813 PR: https://git.openjdk.org/jdk/pull/11813 From mbaesken at openjdk.org Wed Jan 4 11:43:59 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 11:43:59 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v3] In-Reply-To: References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> <-JJb5gUUjle7DgCqjXuPm9h6hnCWHMEBm6VlrYbihzs=.edb76d2e-c31f-48db-97cb-0671bd4e1eae@github.com> Message-ID: On Wed, 4 Jan 2023 10:00:51 GMT, Alan Bateman wrote: >> Hi Alan, I adjusted this coding following your suggestion to use setStackTrace. > >> Hi Alan, I adjusted this coding following your suggestion to use setStackTrace. > > That's just one of them. In a later comment I pasted in asSocketException and changed all 4 cases to use it, maybe you could try that. The right thing is of course to drop the translation to SocketException as anything using read/write has to deal with IOException anyway, it's really just a concern that older code may having special handling of SocketException of undocumented, but longstanding, behavior in older JDK releases. Sorry Alan, seems I somehow missed that. I pushed a new commit including asSocketException . I wonder, could asSocketException in the form of asOtherException maybe be a useful generics that covers multiple exception classes (but that would be something for another PR) ? public static T asOtherException(Exception e, T n) { ... } (maybe we could omit the second param somehow, not sure.) ------------- PR: https://git.openjdk.org/jdk/pull/11813 From alanb at openjdk.org Wed Jan 4 15:03:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 4 Jan 2023 15:03:52 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v6] In-Reply-To: References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: On Wed, 4 Jan 2023 11:36:13 GMT, Matthias Baesken wrote: >> We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce asSocketException in nio Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11813 From alanb at openjdk.org Wed Jan 4 15:03:53 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 4 Jan 2023 15:03:53 GMT Subject: RFR: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area [v3] In-Reply-To: References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> <-JJb5gUUjle7DgCqjXuPm9h6hnCWHMEBm6VlrYbihzs=.edb76d2e-c31f-48db-97cb-0671bd4e1eae@github.com> Message-ID: On Wed, 4 Jan 2023 11:41:10 GMT, Matthias Baesken wrote: >>> Hi Alan, I adjusted this coding following your suggestion to use setStackTrace. >> >> That's just one of them. In a later comment I pasted in asSocketException and changed all 4 cases to use it, maybe you could try that. The right thing is of course to drop the translation to SocketException as anything using read/write has to deal with IOException anyway, it's really just a concern that older code may having special handling of SocketException of undocumented, but longstanding, behavior in older JDK releases. > > Sorry Alan, seems I somehow missed that. I pushed a new commit including asSocketException . > > > I wonder, could asSocketException in the form of asOtherException maybe be a useful generics that covers multiple exception classes (but that would be something for another PR) ? > > public static T asOtherException(Exception e, T n) { > ... > } > > (maybe we could omit the second param somehow, not sure.) If there were other translations needed then it might be useful but I don't think we need it for this change. So I think go with what you have now and we can re-visit it another time if needed, hopefully to remove it (at least for read/write) as the translation shouldn't be required. ------------- PR: https://git.openjdk.org/jdk/pull/11813 From djelinski at openjdk.org Wed Jan 4 16:18:58 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 4 Jan 2023 16:18:58 GMT Subject: RFR: 6914801: IPv6 unavailable if stdin is a socket [v2] In-Reply-To: References: Message-ID: <44x9XnQFeKdHaydNCCCjkrc5n4zcupMwbd3a5qYY4qw=.af9b8ef3-b4b1-44d6-9855-0de0a6fb7b3a@github.com> > This patch reenables IPv6 stack when stdin is an IPv4 socket. > > The code that blocked IPv6 was introduced in JDK-4673940 back when JDK could only operate with either IPv4 or IPv6 sockets, and was using `IPv6_available` to determine which socket type was in use. Now that JDK is able to operate with both IPv4 and IPv6 sockets at the same time, the check for IPv4 stdin is no longer relevant. > > Included test passes with the changes applied, fails without them. Other tier1-3 tests also pass. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Additional logging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11638/files - new: https://git.openjdk.org/jdk/pull/11638/files/ba35ebc2..f8866cf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11638&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11638&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11638.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11638/head:pull/11638 PR: https://git.openjdk.org/jdk/pull/11638 From djelinski at openjdk.org Wed Jan 4 16:18:59 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 4 Jan 2023 16:18:59 GMT Subject: RFR: 6914801: IPv6 unavailable if stdin is a socket [v2] In-Reply-To: <-WB063qWyxVeQzaciIVXaQRtNPOZRxIQd5b0lUNdZjY=.d07726ef-a3f7-4366-aecb-34c47a78288f@github.com> References: <-WB063qWyxVeQzaciIVXaQRtNPOZRxIQd5b0lUNdZjY=.d07726ef-a3f7-4366-aecb-34c47a78288f@github.com> Message-ID: On Tue, 3 Jan 2023 18:26:36 GMT, Michael McMahon wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional logging > > test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java line 112: > >> 110: try (ServerSocketChannel ssc = ch) { >> 111: ssc.socket().bind(new InetSocketAddress(InetAddress.getLoopbackAddress(), 0)); >> 112: SocketChannel sc1 = SocketChannel.open(ssc.getLocalAddress()); > > Could we add some logging/printlns here to indicate the protocol family of `ch` or its local address, to aid in debugging if we ever have problems with the test (eg on IPv6 only systems)? Added; now it produces output like: Using INET (IPv4) channel Socket bound to /127.0.0.1:44179 ------------- PR: https://git.openjdk.org/jdk/pull/11638 From mbaesken at openjdk.org Thu Jan 5 08:29:56 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 5 Jan 2023 08:29:56 GMT Subject: Integrated: JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area In-Reply-To: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> References: <_9rfakta5KnOpV04qXWXB31n4hmIXHaFFctkixmnXs4=.4bd0a2f7-d584-4260-bb69-cf2bde8762a2@github.com> Message-ID: On Mon, 2 Jan 2023 16:16:08 GMT, Matthias Baesken wrote: > We have a couple of places where a SocketException is thrown but the cause is omitted. It would be beneficial for example in error analysis not to throw away the cause (causing exception) but to add it to the created SocketException. This pull request has now been integrated. Changeset: c929d8be Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/c929d8be5d19f2030406eb5c19f854e672c7a547 Stats: 25 lines in 4 files changed: 17 ins; 0 del; 8 mod 8299475: Enhance SocketException by cause where it is missing in net and nio area Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/11813 From michaelm at openjdk.org Thu Jan 5 09:46:50 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 5 Jan 2023 09:46:50 GMT Subject: RFR: 6914801: IPv6 unavailable if stdin is a socket [v2] In-Reply-To: <44x9XnQFeKdHaydNCCCjkrc5n4zcupMwbd3a5qYY4qw=.af9b8ef3-b4b1-44d6-9855-0de0a6fb7b3a@github.com> References: <44x9XnQFeKdHaydNCCCjkrc5n4zcupMwbd3a5qYY4qw=.af9b8ef3-b4b1-44d6-9855-0de0a6fb7b3a@github.com> Message-ID: <0lrZBK5ZjXs6FEVRwQ_qFmGw3_8W0x3oP8Cl23vJIXU=.282bb089-98e5-4307-9e09-33159f87ba4b@github.com> On Wed, 4 Jan 2023 16:18:58 GMT, Daniel Jeli?ski wrote: >> This patch reenables IPv6 stack when stdin is an IPv4 socket. >> >> The code that blocked IPv6 was introduced in JDK-4673940 back when JDK could only operate with either IPv4 or IPv6 sockets, and was using `IPv6_available` to determine which socket type was in use. Now that JDK is able to operate with both IPv4 and IPv6 sockets at the same time, the check for IPv4 stdin is no longer relevant. >> >> Included test passes with the changes applied, fails without them. Other tier1-3 tests also pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Additional logging LGTM ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.org/jdk/pull/11638 From alanb at openjdk.org Thu Jan 5 09:51:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 5 Jan 2023 09:51:54 GMT Subject: RFR: 6914801: IPv6 unavailable if stdin is a socket In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 12:36:17 GMT, Michael McMahon wrote: > Happy new year! Thanks Alan for checking this. Can I get a more formal review? I didn't get time to study the test changes but I see Michael did, so I think you are good to go. ------------- PR: https://git.openjdk.org/jdk/pull/11638 From bpb at openjdk.org Thu Jan 5 22:33:48 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 5 Jan 2023 22:33:48 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly Message-ID: Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. ------------- Commit messages: - 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly Changes: https://git.openjdk.org/jdk/pull/11873/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299684 Stats: 21 lines in 2 files changed: 12 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From psandoz at openjdk.org Thu Jan 5 23:25:50 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 5 Jan 2023 23:25:50 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly In-Reply-To: References: Message-ID: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> On Thu, 5 Jan 2023 22:25:19 GMT, Brian Burkhalter wrote: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Requires an update to the JNI spec and therefore a CSR? src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 249: > 247: return Math.toIntExact(capacity); > 248: } catch (ArithmeticException ignore) { > 249: throw new IllegalArgumentException("capacity " + capacity I think we should mention the source, that the capacity value originates from a native call to NewDirectByteBuffer, since that will not appear in any frames of the reported stack trace. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 5 23:25:50 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 5 Jan 2023 23:25:50 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly In-Reply-To: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> References: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> Message-ID: <6XtN6Ds03G9CeeL2_eUjbtlAi3NSq-pL6-o9zXRJSzI=.fca79da0-0e2f-44ae-8900-3639ab9a0f5c@github.com> On Thu, 5 Jan 2023 23:19:53 GMT, Paul Sandoz wrote: > I think we should mention the source, that the capacity value originates from a native call to NewDirectByteBuffer [...] So you mean in the IAE message itself? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 5 23:31:47 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 5 Jan 2023 23:31:47 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly In-Reply-To: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> References: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> Message-ID: <-VLIE3QIHpofdg5puizvukVzpmvlniQ8ehZS5WJMdNI=.b24bc2b2-5316-472f-9ddf-76d6bdf1d05b@github.com> On Thu, 5 Jan 2023 23:20:40 GMT, Paul Sandoz wrote: > Requires an update to the JNI spec and therefore a CSR? Yes, I think both. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From psandoz at openjdk.org Thu Jan 5 23:31:50 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 5 Jan 2023 23:31:50 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly In-Reply-To: <6XtN6Ds03G9CeeL2_eUjbtlAi3NSq-pL6-o9zXRJSzI=.fca79da0-0e2f-44ae-8900-3639ab9a0f5c@github.com> References: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> <6XtN6Ds03G9CeeL2_eUjbtlAi3NSq-pL6-o9zXRJSzI=.fca79da0-0e2f-44ae-8900-3639ab9a0f5c@github.com> Message-ID: On Thu, 5 Jan 2023 23:22:34 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 249: >> >>> 247: return Math.toIntExact(capacity); >>> 248: } catch (ArithmeticException ignore) { >>> 249: throw new IllegalArgumentException("capacity " + capacity >> >> I think we should mention the source, that the capacity value originates from a native call to NewDirectByteBuffer, since that will not appear in any frames of the reported stack trace. > >> I think we should mention the source, that the capacity value originates from a native call to NewDirectByteBuffer [...] > > So you mean in the IAE message itself? Yes, enhance the message with more detail ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 5 23:42:11 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 5 Jan 2023 23:42:11 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v2] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Enhance message in IAE caused by NewDirectByteBuffer passing up a capacity which overflows int range ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/8baa0fbb..db924a34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From duke at openjdk.org Fri Jan 6 02:45:18 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 02:45:18 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor Message-ID: This PR adds a new lint warning category `this-escape`. It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) * Some constructor `B()` of `B` invokes `A()` as its superclass constructor * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. **Patch Navigation Guide** * Non-trivial compiler changes: * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` * Javadoc additions of `@implNote`: * `src/java.base/share/classes/java/io/PipedReader.java` * `src/java.base/share/classes/java/io/PipedWriter.java` * `src/java.base/share/classes/java/lang/Throwable.java` * `src/java.base/share/classes/java/util/ArrayDeque.java` * `src/java.base/share/classes/java/util/EnumMap.java` * `src/java.base/share/classes/java/util/HashSet.java` * `src/java.base/share/classes/java/util/Hashtable.java` * `src/java.base/share/classes/java/util/LinkedList.java` * `src/java.base/share/classes/java/util/TreeMap.java` * `src/java.base/share/classes/java/util/TreeSet.java` * New unit tests * `test/langtools/tools/javac/warnings/ThisEscape/*.java` * **Everything else** is just adding `@SuppressWarnings("this-escape")` ------------- Commit messages: - Remove trailing whitespace. - Some documentation tweaks. - Treat method references like the equivalent lambda. - Fix bug where initializers could generate duplicate warnings. - Javadoc fix. - Add ThisEscape.html doc note and link the new @implNote's to it. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - ... and 38 more: https://git.openjdk.org/jdk/compare/c6588d5b...9c162283 Changes: https://git.openjdk.org/jdk/pull/11874/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8015831 Stats: 4326 lines in 1285 files changed: 4259 ins; 3 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From dholmes at openjdk.org Fri Jan 6 04:51:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 6 Jan 2023 04:51:00 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Hi Archie, The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From dholmes at openjdk.org Fri Jan 6 06:54:49 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 6 Jan 2023 06:54:49 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 23:42:11 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Enhance message in IAE caused by NewDirectByteBuffer passing up a capacity which overflows int range I think it will look strange to update the JNI spec to say that although the function takes a jlong as the requested capacity, it will throw IAE if the capacity is larger than a jint! The mismatch between the JNI and Java code made me dig into the history here to see what JSR-51 had to say about this, but unfortunately it didn't say much. What I did find in https://bugs.openjdk.org/browse/JDK-4496703 was a very definitive comment about only supporting 32-bit (ie int) based direct buffers, but with a glimmer of hope > "A future revision of the specification is likely to address this problem". So perhaps the JNI side was prepared for this unrealized future? But even so it should have specified what happens if the jlong capacity exceeds the value of a jint I thought perhaps a special OutOfMemoryError (akin to the "Requested array size exceeds VM limit" OOME) could be thrown - and that would not require a JNI spec change - but it is a stretch. Though also note that if this requires a JNI spec change then it cannot be backported without jumping through some serious JCP Maintenance Release hoops. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Fri Jan 6 07:53:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Jan 2023 07:53:54 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` This looks like a very useful lint warning to have but this PR is unwieldy. If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From alanb at openjdk.org Fri Jan 6 09:06:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Jan 2023 09:06:49 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 23:42:11 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Enhance message in IAE caused by NewDirectByteBuffer passing up a capacity which overflows int range I checked ancient history and the issue goes back to JDK 1.4 (when JSR-51 defined this API). It's surprising that it hasn't been reported/noticed before now. Yes, this will need an update to the JNI spec to say that it throws if capacity is negative or greater than Integer.MAX_VALUE. It will look a bit strange in the spec when the parameter is jlong but we can't change it. As regards what to throw then the current proposal to throw IAE seems okay as the function already throws it for negative values that are >= Integer.MIN_VALUE, e.g. Exception in thread "main" java.lang.IllegalArgumentException: capacity < 0: (-1 < 0) at java.base/java.nio.Buffer.createCapacityException(Buffer.java:282) at java.base/java.nio.Buffer.(Buffer.java:245) at java.base/java.nio.ByteBuffer.(ByteBuffer.java:298) at java.base/java.nio.ByteBuffer.(ByteBuffer.java:306) at java.base/java.nio.MappedByteBuffer.(MappedByteBuffer.java:113) at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:177) at Test.newDirectByteBuffer(Native Method) at Test.main(Test.java:7) The compatibility impact of the change should be minimal, at least I can't imagine anyone depending on the current broken behavior. For the change, clampCapacity only needs to be called once, not twice. The exception message is a bit strange. If cap is < Integer.MIN_VALUE then it would be better to have it consistent with the existing message above. Also "in upcall from JNI NewDirectByteBuffer" should be better if it didn't include "in upcall". We will need to add a test for this and decide whether to place it. It seems there aren't any tests for these JNI functions in hotspot//jtreg/runtime/jni, maybe we start a new locations for tests in test/jdk/java/nio/jni. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From duke at openjdk.org Fri Jan 6 14:51:54 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 14:51:54 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 04:48:27 GMT, David Holmes wrote: > The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? Hi @dholmes-ora, The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc. Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds. Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. > If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. Hi @AlanBateman, As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well. > I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? If this is generally agreed as a better route then let me know and I'll update the patch. Thanks for both of your comments. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From alanb at openjdk.org Fri Jan 6 15:41:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Jan 2023 15:41:16 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 14:49:16 GMT, Archie L. Cobbs wrote: > Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? > > If this is generally agreed as a better route then let me know and I'll update the patch. Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Fri Jan 6 15:57:50 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 6 Jan 2023 15:57:50 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman wrote: >>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? >> >> Hi @dholmes-ora, >> >> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc. >> >> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds. >> >> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. >> >>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. >> >> Hi @AlanBateman, >> >> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well. >> >>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. >> >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. >> >> Thanks for both of your comments. > >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. > > Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. I agree with @AlanBateman. When we introduced similar warnings in the past, we have enabled support in javac (with some test) in a separate PR, and then followed up with small dedicated PR for each of the various areas (enabling new warnings one by one). See this great umbrella JBS issue (created by @asotona) which has details on all the issues that were filed when we added an extra Lint warning for lossy conversions: https://bugs.openjdk.org/browse/JDK-8286374 They all refer to this: https://bugs.openjdk.org/browse/JDK-8244681 Which was submitted as a separate javac-only PR: https://github.com/openjdk/jdk/pull/8599 ------------- PR: https://git.openjdk.org/jdk/pull/11874 From bpb at openjdk.org Fri Jan 6 18:10:28 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 6 Jan 2023 18:10:28 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v3] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Call clampCapacity() only once; change IAE message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/db924a34..a9e44d62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=01-02 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From duke at openjdk.org Fri Jan 6 23:13:09 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 23:13:09 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v2] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year for newly added files to 2023. - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/9c162283..f667cd56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00-01 Stats: 1935 lines in 1303 files changed: 60 ins; 1770 del; 105 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 6 23:13:09 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 23:13:09 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman wrote: >>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? >> >> Hi @dholmes-ora, >> >> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc. >> >> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds. >> >> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. >> >>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. >> >> Hi @AlanBateman, >> >> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well. >> >>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. >> >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. >> >> Thanks for both of your comments. > >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. > > Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. Hi @AlanBateman, OK that sounds like a plan. I've pushed a new commit to the `ThisEscape` branch that removes all the`@SuppressWarnings` annotations and replaces them with adjustments to build flags. I've moved the `@SuppressWarnings` annotations onto a new branch `ThisEscapeAnnotations`. This is just for future reference in case somebody wants to add them back someday and doesn't want to start from scratch. > I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. Hmm. Hasn't that horse already left the barn? You kind of implied that when you said: > I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. In other words, it doesn't sound like changing the behavior of these constructors is viable option at this point. And if that's the case, we might as well document and warn about the current behavior. Of course I'd love to be wrong... in which case, we can fix these constructors. Or, the third option - just do nothing yet. That would mean removing the warnings, which is fine. But then the `ThisEscape.html` document is orphaned. What should we do with it? I can remove it, just leave it there, or put it somewhere else (where?). It seems like having some documentation of the meaning of "this escape" would be helpful, because it's a subtle concept and there are multiple ways to define "escape". Thanks. @mcimadamore thanks for the bugs suggestion, I'll put that on the to-do list. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From bpb at openjdk.org Fri Jan 6 23:56:39 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 6 Jan 2023 23:56:39 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Add test for out of range capacity passed to NewDirectBuffer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/a9e44d62..d8e6c180 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=02-03 Stats: 121 lines in 3 files changed: 120 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From duke at openjdk.org Sat Jan 7 16:24:56 2023 From: duke at openjdk.org (ExE Boss) Date: Sat, 7 Jan 2023 16:24:56 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v2] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 23:13:09 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year for newly added files to 2023. > - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations. src/java.base/share/classes/java/lang/AssertionError.java line 75: > 73: */ > 74: @SuppressWarnings("this-escape") > 75: public AssertionError(Object detailMessage) { The?Javadoc of?this?constructor should?probably?mention that?it?calls `initCause(?)` when?`detailMessage` is?a?`Throwable`. src/java.base/share/classes/java/lang/BootstrapMethodError.java line 77: > 75: * Constructs a {@code BootstrapMethodError} with the specified > 76: * cause. > 77: * Suggestion: * * @implNote This constructor invokes {@link #initCause initCause()}; see * This Escape. * src/java.base/share/classes/java/lang/ExceptionInInitializerError.java line 54: > 52: * throwable object. > 53: * A detail message is a String that describes this particular exception. > 54: */ Suggestion: * * @implNote This constructor invokes {@link #initCause initCause()}; see * This Escape. */ ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Sat Jan 7 16:58:58 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Sat, 7 Jan 2023 16:58:58 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v3] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Add a few more Javadoc warnings for 'this' escape via initCause(). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/f667cd56..398737fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=01-02 Stats: 9 lines in 3 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From alanb at openjdk.org Sat Jan 7 18:05:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 7 Jan 2023 18:05:50 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 23:08:27 GMT, Archie L. Cobbs wrote: > I've moved the `@SuppressWarnings` annotations onto a new branch `ThisEscapeAnnotations`. This is just for future reference in case somebody wants to add them back someday and doesn't want to start from scratch. > > > I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. > > Hmm. Hasn't that horse already left the barn? You kind of implied that when you said: > > > I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. > > In other words, it doesn't sound like changing the behavior of these constructors is viable option at this point. And if that's the case, we might as well document and warn about the current behavior. > > Of course I'd love to be wrong... in which case, we can fix these constructors. I hope at least some of these can be fixed as leaking a part initialized object to an untrusted subclass or some other code is problematic in many ways. Skimming through the original list, then some of these may be accidental and some may be fixable without any compatibility concerns, esp. in the JDK internal classes. Yes, some horses have left the barn. A horse that got out a long time ago is j.net.ServerSocket where 3 of its constructors call an overridable bind method. Recent re-implementation would have fixed this but there were concerns that subclasses may be relying on this long standing undocumented behavior. There are other cases in the list where the leaking may be necessary part of the contract for subclasses. So it will probably require working through them on a case by case basis. I don't think the implementation notes should be included as part of the adding the lint warning as I think it creates an attractive nuisance. Developers reading these implementation notes may c reate code that depends on these "hooks" and it will make it very hard for the JDK to ever change the behavior. Where the leaking is a necessary part of the contract for subclassing then it may be that it has to be documented as normative text rather than an implementation note. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Sat Jan 7 19:52:49 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Sat, 7 Jan 2023 19:52:49 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Sat, 7 Jan 2023 18:03:04 GMT, Alan Bateman wrote: > I don't think the implementation notes should be included as part of the adding the lint warning as I think it creates an attractive nuisance. I agree with you - not only for that reason, but also because as others have pointed out the addition of the warning is really a separate task from the evaluation and triage of any existing leaks. Moreover, this latter task is really multiple separate tasks that belong to the various module/functional groups. I'll remove all the Javadoc `@implNote`'s from the patch, and `src/java.base/share/classes/java/lang/doc-files/ThisEscape.html` as well - it will still be available in the git history if someone comes up with a better home for it. This will also further reduce the number of labels and therefore required reviewers. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Sat Jan 7 19:59:59 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Sat, 7 Jan 2023 19:59:59 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v4] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Remove Javadoc @implNotes; plan to triage the various existing leaks separately. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/398737fa..537b3e3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=02-03 Stats: 255 lines in 29 files changed: 0 ins; 251 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From dholmes at openjdk.org Mon Jan 9 05:54:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jan 2023 05:54:55 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 23:56:39 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Add test for out of range capacity passed to NewDirectBuffer Changes requested by dholmes (Reviewer). make/test/JtregNativeJdk.gmk line 81: > 79: > 80: BUILD_JDK_JTREG_LIBRARIES_LIBS_libTracePinnedThreads := jvm.lib > 81: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := -ljava -lc This is not correct for Windows make/test/JtregNativeJdk.gmk line 85: > 83: BUILD_JDK_JTREG_LIBRARIES_LIBS_libstringPlatformChars := -ljava > 84: BUILD_JDK_JTREG_LIBRARIES_LIBS_libDirectIO := -ljava > 85: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := -ljava -lc Why do we need `-lc`? src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 245: > 243: // Constrain the capacity to int range throwing IAE if not possible > 244: // > 245: private static int clampCapacity(long capacity) { I think `checkCapacity` would be better - clamp suggests the value gets clamped rather than throwing an exception. src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 247: > 245: private static int clampCapacity(long capacity) { > 246: try { > 247: return Math.toIntExact(capacity); Why not the more direct and obvious: if (capacity < 0) { throw ... } else if (capacity > Integer.MAX_VALUE) { throw ... } src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 251: > 249: String msg = "JNI NewDirectByteBuffer passed illegal capacity: " > 250: + capacity + (capacity < Integer.MIN_VALUE > 251: ? " < Integer.MIN_VALUE" : " > Integer.MAX_VALUE"); Why the check against `MIN_VALUE`? test/jdk/java/nio/jni/NewDirectByteBuffer.java line 49: > 47: 1L, > 48: (long)Integer.MAX_VALUE - 1, > 49: (long)Integer.MAX_VALUE Won't such large capacities trigger OOME? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From djelinski at openjdk.org Mon Jan 9 07:45:01 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 9 Jan 2023 07:45:01 GMT Subject: Integrated: 6914801: IPv6 unavailable if stdin is a socket In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 20:30:05 GMT, Daniel Jeli?ski wrote: > This patch reenables IPv6 stack when stdin is an IPv4 socket. > > The code that blocked IPv6 was introduced in JDK-4673940 back when JDK could only operate with either IPv4 or IPv6 sockets, and was using `IPv6_available` to determine which socket type was in use. Now that JDK is able to operate with both IPv4 and IPv6 sockets at the same time, the check for IPv4 stdin is no longer relevant. > > Included test passes with the changes applied, fails without them. Other tier1-3 tests also pass. This pull request has now been integrated. Changeset: 8d17d1ee Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/8d17d1ee6f08ee90771d469182aaaaa7c23971fd Stats: 199 lines in 7 files changed: 161 ins; 22 del; 16 mod 6914801: IPv6 unavailable if stdin is a socket Reviewed-by: michaelm ------------- PR: https://git.openjdk.org/jdk/pull/11638 From alanb at openjdk.org Mon Jan 9 08:42:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 9 Jan 2023 08:42:52 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 23:56:39 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Add test for out of range capacity passed to NewDirectBuffer I agree with David that it would be clearer and simpler to check if capacity is negative or greater than Integer.MAX_VALUE. There other helper methods called from this code and they are named checkXXX so it would be good to keep that consistent if you can. We don't have other tests for this JNI function in the test tree so having the new tests be a complete unit test would be good. This means checking the position, limit, and capacity of the ByteBuffer and testing that it's a direct buffer. If you make it a JUnit test then you'll be able to paramatrized test with value sources, and use the assertions API when checking each of the buffer properties. For the native code used by the test then it would be clearer if allocBigBuffer were renamed to newDirectByteBuffer. Also I think you'll need to check the value from malloc in case it fails. You'll need another native function to free the memory and have the tests invoke the free in a finally block so that memory doesn't accumulate as the test cycles through the different buffer sizes. Right now, I assume the tests don't run on 32-bit as it mallocs two 2Gb areas. Once the test is re-worded then you can get a sense as to how much memory it needs and whether you need a @requires in the test description to ensue that the test system has sufficient memory. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Mon Jan 9 08:45:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 9 Jan 2023 08:45:52 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: <1deRMd9Z4swBHRwfUtX5_-XNYuHpYv7PKi4Gf3gjJXA=.e23bf8cf-041f-48e2-916d-33273161a8b9@github.com> On Mon, 9 Jan 2023 05:51:15 GMT, David Holmes wrote: > Won't such large capacities trigger OOME? The malloc might fail, in which case the value of NULL will be passed to NewDirectByteBuffer. It needs to check the return from malloc. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Mon Jan 9 19:29:58 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Jan 2023 19:29:58 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> <6XtN6Ds03G9CeeL2_eUjbtlAi3NSq-pL6-o9zXRJSzI=.fca79da0-0e2f-44ae-8900-3639ab9a0f5c@github.com> Message-ID: On Thu, 5 Jan 2023 23:27:34 GMT, Paul Sandoz wrote: >>> I think we should mention the source, that the capacity value originates from a native call to NewDirectByteBuffer [...] >> >> So you mean in the IAE message itself? > > Yes, enhance the message with more detail Fixed in a9e44d62414d6d241b523edd3350103bcafac5cc. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Mon Jan 9 23:14:56 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Jan 2023 23:14:56 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 05:40:57 GMT, David Holmes wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Add test for out of range capacity passed to NewDirectBuffer > > make/test/JtregNativeJdk.gmk line 81: > >> 79: >> 80: BUILD_JDK_JTREG_LIBRARIES_LIBS_libTracePinnedThreads := jvm.lib >> 81: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := -ljava -lc > > This is not correct for Windows Do you have a suggestion? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Tue Jan 10 02:20:34 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Jan 2023 02:20:34 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Changes addressing reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/d8e6c180..d2386a4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=03-04 Stats: 107 lines in 4 files changed: 70 ins; 13 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Tue Jan 10 02:20:37 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Jan 2023 02:20:37 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 08:40:02 GMT, Alan Bateman wrote: > If you make it a JUnit test then you'll be able to paramatrized test with value sources, and use the assertions API when checking each of the buffer properties. All points addressed in d2386a4b73f0fa4eb9cc278b3cbb1578e6cb4b55 except converting to a JUnit test. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Tue Jan 10 02:20:43 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Jan 2023 02:20:43 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: <1deRMd9Z4swBHRwfUtX5_-XNYuHpYv7PKi4Gf3gjJXA=.e23bf8cf-041f-48e2-916d-33273161a8b9@github.com> References: <1deRMd9Z4swBHRwfUtX5_-XNYuHpYv7PKi4Gf3gjJXA=.e23bf8cf-041f-48e2-916d-33273161a8b9@github.com> Message-ID: On Mon, 9 Jan 2023 08:42:58 GMT, Alan Bateman wrote: >> test/jdk/java/nio/jni/NewDirectByteBuffer.java line 49: >> >>> 47: 1L, >>> 48: (long)Integer.MAX_VALUE - 1, >>> 49: (long)Integer.MAX_VALUE >> >> Won't such large capacities trigger OOME? > >> Won't such large capacities trigger OOME? > > The malloc might fail, in which case the value of NULL will be passed to NewDirectByteBuffer. It needs to check the return from malloc. Fixed in d2386a4b73f0fa4eb9cc278b3cbb1578e6cb4b55. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Tue Jan 10 02:20:41 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Jan 2023 02:20:41 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 05:41:44 GMT, David Holmes wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Add test for out of range capacity passed to NewDirectBuffer > > make/test/JtregNativeJdk.gmk line 85: > >> 83: BUILD_JDK_JTREG_LIBRARIES_LIBS_libstringPlatformChars := -ljava >> 84: BUILD_JDK_JTREG_LIBRARIES_LIBS_libDirectIO := -ljava >> 85: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := -ljava -lc > > Why do we need `-lc`? No. Removed in d2386a4b73f0fa4eb9cc278b3cbb1578e6cb4b55. > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 245: > >> 243: // Constrain the capacity to int range throwing IAE if not possible >> 244: // >> 245: private static int clampCapacity(long capacity) { > > I think `checkCapacity` would be better - clamp suggests the value gets clamped rather than throwing an exception. So changed in d2386a4b73f0fa4eb9cc278b3cbb1578e6cb4b55. > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 247: > >> 245: private static int clampCapacity(long capacity) { >> 246: try { >> 247: return Math.toIntExact(capacity); > > Why not the more direct and obvious: > > if (capacity < 0) { > throw ... > } else if (capacity > Integer.MAX_VALUE) { > throw ... > } So changed in d2386a4b73f0fa4eb9cc278b3cbb1578e6cb4b55. > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 251: > >> 249: String msg = "JNI NewDirectByteBuffer passed illegal capacity: " >> 250: + capacity + (capacity < Integer.MIN_VALUE >> 251: ? " < Integer.MIN_VALUE" : " > Integer.MAX_VALUE"); > > Why the check against `MIN_VALUE`? It was the lower bound for `toIntExact()` but not relevant any more. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From dholmes at openjdk.org Tue Jan 10 05:57:53 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jan 2023 05:57:53 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 23:12:00 GMT, Brian Burkhalter wrote: >> make/test/JtregNativeJdk.gmk line 81: >> >>> 79: >>> 80: BUILD_JDK_JTREG_LIBRARIES_LIBS_libTracePinnedThreads := jvm.lib >>> 81: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := -ljava -lc >> >> This is not correct for Windows > > Do you have a suggestion? BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := jvm.lib as per the preceding line. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From dholmes at openjdk.org Tue Jan 10 06:06:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jan 2023 06:06:55 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 02:20:34 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Changes addressing reviewer comments Updates look good - thanks. A few minor nits. src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 197: > 195: throw new IllegalArgumentException > 196: ("JNI NewDirectByteBuffer passed capacity < 0: (" > 197: + capacity + " < 0)"); You don't need to repeat the `< 0` part. src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 201: > 199: throw new IllegalArgumentException > 200: ("JNI NewDirectByteBuffer passed capacity > Integer.MAX_VALUE: (" > 201: + capacity + " > Integer.MAX_VALUE)"); You don't need to repeat the `> Integer.MAX_VALUE` part. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 73: > 71: public static void main(String[] args) { > 72: System.out.println("--- Legal Capacities ---"); > 73: for (long cap : LEGAL_CAPACITIES) { I would still expect this to throw OOME for the very large values, so the OOME needs to be caught so that the test continues. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 106: > 104: private static native ByteBuffer newDirectByteBuffer(long size); > 105: private static native long getDirectBufferCapacity(ByteBuffer buf); > 106: private static native void freeDirectBufferMemory(ByteBuffer buf); Naming nit: ByteBuffer versus Buffer ------------- PR: https://git.openjdk.org/jdk/pull/11873 From dholmes at openjdk.org Tue Jan 10 06:11:53 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jan 2023 06:11:53 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 05:54:53 GMT, David Holmes wrote: >> Do you have a suggestion? > > BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := jvm.lib > > as per the preceding line. Sorry, my bad, that should be: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := $(WIN_LIB_JAVA) the Windows equivalent of `-ljava`. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Tue Jan 10 12:04:56 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 10 Jan 2023 12:04:56 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: Message-ID: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> On Tue, 10 Jan 2023 02:20:34 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Changes addressing reviewer comments The update looks quite good and maybe some day this can be converted from a psvm test to a junit test. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 30: > 28: * @summary Verify that JNI NewDirectByteBuffer throws IllegalArgumentException > 29: * if the capacity is negative or greater than Integer::MAX_VALUE > 30: * @run main/native NewDirectByteBuffer You may have missed the comments about @requires and wondering if this test will run on 32-bit, as it will attempt to malloc 2GB. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 50: > 48: (long)Integer.MAX_VALUE + 1L, > 49: 3_000_000_000L, > 50: 5_000_000_000L Long.MIN_VALUE and Long.MAX_VALUE would be good to include. test/jdk/java/nio/jni/libNewDirectByteBuffer.c line 35: > 33: void* addr = malloc(size); > 34: if (addr == NULL) { > 35: jclass rtExCls = (*env)->FindClass(env, "java/lang/OutOfMemoryError"); rtExCls? Does this stand for "runtime exception class", just asking because this is an Error class. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From pminborg at openjdk.org Tue Jan 10 15:33:47 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 10 Jan 2023 15:33:47 GMT Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE Message-ID: This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`. ------------- Commit messages: - Check null invariants Changes: https://git.openjdk.org/jdk/pull/11926/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299864 Stats: 49 lines in 2 files changed: 26 ins; 1 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/11926.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11926/head:pull/11926 PR: https://git.openjdk.org/jdk/pull/11926 From lancea at openjdk.org Tue Jan 10 17:34:57 2023 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 10 Jan 2023 17:34:57 GMT Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 15:26:05 GMT, Per Minborg wrote: > This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`. Thanks for taking this on Per. I think we also need to add a test for getAttribute() and getFileStoreAttributeView() as I do not see it being tested in test/jdk/jdk/nio/zipfs/ZipFSTester.java or test/jdk/jdk/nio/zipfs/Basic.java A few more minor comments below: src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileStore.java line 43: > 41: * @author Xueming Shen, Rajendra Gutupalli, Jaya Hangal > 42: */ > 43: final class ZipFileStore extends FileStore { This should be OK but might suggest adding a release note test/jdk/jdk/nio/zipfs/ZipFSTester.java line 1086: > 1084: } > 1085: > 1086: static void test8299864(FileSystem fs) { Please add a comment explaining the test and change the method name as would prefer to have names that are a bit more descriptive than a bug number. I realize some of the existing methods follow the same naming as you are proposing, but we are trying to avoid this and make the tests more descriptive going forward ------------- PR: https://git.openjdk.org/jdk/pull/11926 From pminborg at openjdk.org Wed Jan 11 08:35:00 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 11 Jan 2023 08:35:00 GMT Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE [v2] In-Reply-To: References: Message-ID: > This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Rename and improve NPE testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11926/files - new: https://git.openjdk.org/jdk/pull/11926/files/9e6e8e54..8c465592 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=00-01 Stats: 26 lines in 1 file changed: 17 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11926.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11926/head:pull/11926 PR: https://git.openjdk.org/jdk/pull/11926 From pminborg at openjdk.org Wed Jan 11 08:35:02 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 11 Jan 2023 08:35:02 GMT Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE [v2] In-Reply-To: References: Message-ID: <31Uf6u2Ivx4P23s-aSTNoGCFCwAL4O3z-wNLocXYqY4=.2eb1215c-4c79-4dbc-a228-fc07079c1927@github.com> On Tue, 10 Jan 2023 17:29:56 GMT, Lance Andersen wrote: > This should be OK but might suggest adding a release note Do we need to do that for a package-private class? Maybe for internal use? ------------- PR: https://git.openjdk.org/jdk/pull/11926 From pminborg at openjdk.org Wed Jan 11 08:39:17 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 11 Jan 2023 08:39:17 GMT Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE [v3] In-Reply-To: References: Message-ID: > This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add test method comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11926/files - new: https://git.openjdk.org/jdk/pull/11926/files/8c465592..84813af1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=01-02 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11926.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11926/head:pull/11926 PR: https://git.openjdk.org/jdk/pull/11926 From pminborg at openjdk.org Wed Jan 11 08:43:36 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 11 Jan 2023 08:43:36 GMT Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE [v4] In-Reply-To: References: Message-ID: <-aFDK_amcmbOhLES8mG-8lWJy8aHQIKMgc2FgleoMUI=.b1fddeaf-c3f8-454c-80ef-942d633bee5a@github.com> > This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Fix typo and add bug ref ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11926/files - new: https://git.openjdk.org/jdk/pull/11926/files/84813af1..6003faae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11926.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11926/head:pull/11926 PR: https://git.openjdk.org/jdk/pull/11926 From alanb at openjdk.org Wed Jan 11 09:02:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 11 Jan 2023 09:02:16 GMT Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE [v4] In-Reply-To: <31Uf6u2Ivx4P23s-aSTNoGCFCwAL4O3z-wNLocXYqY4=.2eb1215c-4c79-4dbc-a228-fc07079c1927@github.com> References: <31Uf6u2Ivx4P23s-aSTNoGCFCwAL4O3z-wNLocXYqY4=.2eb1215c-4c79-4dbc-a228-fc07079c1927@github.com> Message-ID: On Wed, 11 Jan 2023 08:30:01 GMT, Per Minborg wrote: >> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileStore.java line 43: >> >>> 41: * @author Xueming Shen, Rajendra Gutupalli, Jaya Hangal >>> 42: */ >>> 43: final class ZipFileStore extends FileStore { >> >> This should be OK but might suggest adding a release note > >> This should be OK but might suggest adding a release note > > Do we need to do that for a package-private class? Maybe for internal use? This is a implementation class in a non-exported package so it's okay. ------------- PR: https://git.openjdk.org/jdk/pull/11926 From lancea at openjdk.org Wed Jan 11 14:17:15 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 11 Jan 2023 14:17:15 GMT Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE [v4] In-Reply-To: <-aFDK_amcmbOhLES8mG-8lWJy8aHQIKMgc2FgleoMUI=.b1fddeaf-c3f8-454c-80ef-942d633bee5a@github.com> References: <-aFDK_amcmbOhLES8mG-8lWJy8aHQIKMgc2FgleoMUI=.b1fddeaf-c3f8-454c-80ef-942d633bee5a@github.com> Message-ID: On Wed, 11 Jan 2023 08:43:36 GMT, Per Minborg wrote: >> This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo and add bug ref Thank you for the updates Per. The changes look fine. At a later date we should additional tests for the the non-null values passed to getAttribute et.al. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.org/jdk/pull/11926 From lancea at openjdk.org Wed Jan 11 14:17:16 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 11 Jan 2023 14:17:16 GMT Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE [v4] In-Reply-To: References: <31Uf6u2Ivx4P23s-aSTNoGCFCwAL4O3z-wNLocXYqY4=.2eb1215c-4c79-4dbc-a228-fc07079c1927@github.com> Message-ID: On Wed, 11 Jan 2023 08:59:53 GMT, Alan Bateman wrote: > This is a implementation class in a non-exported package so it's okay. Fair point ------------- PR: https://git.openjdk.org/jdk/pull/11926 From pminborg at openjdk.org Wed Jan 11 15:12:19 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 11 Jan 2023 15:12:19 GMT Subject: Integrated: 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 15:26:05 GMT, Per Minborg wrote: > This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`. This pull request has now been integrated. Changeset: 7d3400b1 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/7d3400b1cf6befd28af81113b218d0aae60ac05f Stats: 68 lines in 2 files changed: 45 ins; 1 del; 22 mod 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/11926 From pminborg at openjdk.org Wed Jan 11 15:13:09 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 11 Jan 2023 15:13:09 GMT Subject: RFR: 8299976: Initialize static fields in Net eagerly Message-ID: This PR proposes initializing some static fields eagerly using `final` fields. This will improve performance slightly and will allow us to remove two static fields. The PR also contains "blessed" variable casing and deduplication of exception creation. ------------- Commit messages: - Update copyright year - Revert MC access - Use MH and deduplicate exeption constuction - Rollback changes - Initialize Net eagerly, improve in accessors and cleanup Changes: https://git.openjdk.org/jdk/pull/11948/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11948&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299976 Stats: 98 lines in 1 file changed: 13 ins; 15 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/11948.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11948/head:pull/11948 PR: https://git.openjdk.org/jdk/pull/11948 From bpb at openjdk.org Wed Jan 11 17:27:22 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:27:22 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v6] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: More changes addressing reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/d2386a4b..82d9e6f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=04-05 Stats: 53 lines in 5 files changed: 38 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:27:24 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:27:24 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 06:09:21 GMT, David Holmes wrote: >> BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := jvm.lib >> >> as per the preceding line. > > Sorry, my bad, that should be: > > BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := $(WIN_LIB_JAVA) > > the Windows equivalent of `-ljava`. Thanks. So changed in 82d9e6f1f6782b180943d1136881d58dd2852e58. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:27:29 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:27:29 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 05:56:16 GMT, David Holmes wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Changes addressing reviewer comments > > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 197: > >> 195: throw new IllegalArgumentException >> 196: ("JNI NewDirectByteBuffer passed capacity < 0: (" >> 197: + capacity + " < 0)"); > > You don't need to repeat the `< 0` part. I was matching `Buffer::createCapacityException` but I agree with you. Remove in 82d9e6f1f6782b180943d1136881d58dd2852e58. > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 201: > >> 199: throw new IllegalArgumentException >> 200: ("JNI NewDirectByteBuffer passed capacity > Integer.MAX_VALUE: (" >> 201: + capacity + " > Integer.MAX_VALUE)"); > > You don't need to repeat the `> Integer.MAX_VALUE` part. Removed in 82d9e6f1f6782b180943d1136881d58dd2852e58. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 73: > >> 71: public static void main(String[] args) { >> 72: System.out.println("--- Legal Capacities ---"); >> 73: for (long cap : LEGAL_CAPACITIES) { > > I would still expect this to throw OOME for the very large values, so the OOME needs to be caught so that the test continues. Fixed in 82d9e6f1f6782b180943d1136881d58dd2852e58. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:27:32 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:27:32 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> References: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> Message-ID: On Tue, 10 Jan 2023 11:58:03 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Changes addressing reviewer comments > > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 30: > >> 28: * @summary Verify that JNI NewDirectByteBuffer throws IllegalArgumentException >> 29: * if the capacity is negative or greater than Integer::MAX_VALUE >> 30: * @run main/native NewDirectByteBuffer > > You may have missed the comments about @requires and wondering if this test will run on 32-bit, as it will attempt to malloc 2GB. I saw the comments but was deferring that. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 50: > >> 48: (long)Integer.MAX_VALUE + 1L, >> 49: 3_000_000_000L, >> 50: 5_000_000_000L > > Long.MIN_VALUE and Long.MAX_VALUE would be good to include. Added in 82d9e6f1f6782b180943d1136881d58dd2852e58. > test/jdk/java/nio/jni/libNewDirectByteBuffer.c line 35: > >> 33: void* addr = malloc(size); >> 34: if (addr == NULL) { >> 35: jclass rtExCls = (*env)->FindClass(env, "java/lang/OutOfMemoryError"); > > rtExCls? Does this stand for "runtime exception class", just asking because this is an Error class. Thanks for catching that. The name `rtExCls` is as you interpreted and is residual from an unpublished version. Fixed in 82d9e6f1f6782b180943d1136881d58dd2852e58. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:32:28 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:32:28 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v7] In-Reply-To: References: Message-ID: <49RhAcil-2bixbBBctq0uRxYbUd7IzMibHcuG9pLulI=.f331dd43-97a8-4196-b3cd-d59d1a8785bc@github.com> > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Change DirectBuffer to DirectByteBuffer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/82d9e6f1..95fd6652 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=05-06 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:32:31 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:32:31 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 06:00:10 GMT, David Holmes wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Changes addressing reviewer comments > > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 106: > >> 104: private static native ByteBuffer newDirectByteBuffer(long size); >> 105: private static native long getDirectBufferCapacity(ByteBuffer buf); >> 106: private static native void freeDirectBufferMemory(ByteBuffer buf); > > Naming nit: ByteBuffer versus Buffer Fixed in 95fd6652148e1b740af599081b3614c54656c8b4 (overlooked in previous commit). ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:33:16 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:33:16 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> References: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> Message-ID: <5aaxI0fqVOy1ehO53y56S3gcuuXUXwPhxpuLdMsJShQ=.54edb592-8196-488e-b8dd-4e6160070862@github.com> On Tue, 10 Jan 2023 12:02:23 GMT, Alan Bateman wrote: > The update looks quite good and maybe some day this can be converted from a psvm test to a junit test. `JUnit` or `TestNG`? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From lancea at openjdk.org Wed Jan 11 17:52:17 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 11 Jan 2023 17:52:17 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: <5aaxI0fqVOy1ehO53y56S3gcuuXUXwPhxpuLdMsJShQ=.54edb592-8196-488e-b8dd-4e6160070862@github.com> References: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> <5aaxI0fqVOy1ehO53y56S3gcuuXUXwPhxpuLdMsJShQ=.54edb592-8196-488e-b8dd-4e6160070862@github.com> Message-ID: On Wed, 11 Jan 2023 17:31:14 GMT, Brian Burkhalter wrote: > > The update looks quite good and maybe some day this can be converted from a psvm test to a junit test. > > `JUnit` or `TestNG`? It sounds like the suggested way forward is to use junit for new tests and for extra credit convert existing testng tests when/if they need updated ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 23:18:58 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 23:18:58 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v8] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Convert test to JUnit 5; require 64-bit system with at least 8GB of memory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/95fd6652..7f99faee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=06-07 Stats: 76 lines in 1 file changed: 16 ins; 27 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 23:19:01 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 23:19:01 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> Message-ID: On Wed, 11 Jan 2023 17:22:11 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/jni/NewDirectByteBuffer.java line 30: >> >>> 28: * @summary Verify that JNI NewDirectByteBuffer throws IllegalArgumentException >>> 29: * if the capacity is negative or greater than Integer::MAX_VALUE >>> 30: * @run main/native NewDirectByteBuffer >> >> You may have missed the comments about @requires and wondering if this test will run on 32-bit, as it will attempt to malloc 2GB. > > I saw the comments but was deferring that. Added **@requires** in 7f99faeebaea1dc55b592146aa3ba612bdb63d9e. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 23:20:18 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 23:20:18 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 02:15:42 GMT, Brian Burkhalter wrote: > If you make it a JUnit test then you'll be able to paramatrized test with value sources, and use the assertions API when checking each of the buffer properties. Converted to a JUnit test in 7f99faeebaea1dc55b592146aa3ba612bdb63d9e. > Once the test is re-worded then you can get a sense as to how much memory it needs and whether you need a @requires in the test description to ensue that the test system has sufficient memory. Added **@requires** constraining to 64-bit arch and memory at least 8GB in 7f99faeebaea1dc55b592146aa3ba612bdb63d9e. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 12 00:15:45 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Jan 2023 00:15:45 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v9] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Remove spurious file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/7f99faee..5269cae1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=07-08 Stats: 32 lines in 1 file changed: 0 ins; 32 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Thu Jan 12 08:21:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Jan 2023 08:21:21 GMT Subject: RFR: 8299976: Initialize static fields in Net eagerly In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 15:01:54 GMT, Per Minborg wrote: > This PR proposes initializing some static fields eagerly using `final` fields. > > This will improve performance slightly and will allow us to remove two static fields. > > The PR also contains "blessed" variable casing and deduplication of exception creation. src/java.base/share/classes/sun/nio/ch/Net.java line 76: > 74: // -- Miscellaneous utilities -- > 75: > 76: private static final boolean IP_V6_AVAILABLE; The protocol is IPv6 so the underscore between "IP" and "V6" looks strange, maybe IPV6_AVAILABLE would be better. src/java.base/share/classes/sun/nio/ch/Net.java line 77: > 75: > 76: private static final boolean IP_V6_AVAILABLE; > 77: private static final boolean REUSE_PORT_AVAILABLE; The socket option is SO_REUSEPORT so the underscore between "REUSE" and "PORT" looks strange, maybe SO_REUSEPORT_AVAILABLE would be better. src/java.base/share/classes/sun/nio/ch/Net.java line 250: > 248: private static final InetAddress ANY_LOCAL_INET_6_ADDRESS; > 249: private static final InetAddress INET_4_LOOPBACK_ADDRESS; > 250: private static final InetAddress INET_6_LOOPBACK_ADDRESS; The class name is Inet4Address so the name looks a bit strange, maybe INET4 and INE4ADDRESS would be better. src/java.base/share/classes/sun/nio/ch/Net.java line 815: > 813: EXCLUSIVE_BIND = exclBindProp.isEmpty() || Boolean.parseBoolean(exclBindProp); > 814: } else { > 815: EXCLUSIVE_BIND = availLevel == 1; If you put parentheses around "avaiLevel == 1" then it may be a bit more readable. src/java.base/share/classes/sun/nio/ch/Net.java line 833: > 831: private static SocketException newSocketException(String msg) { > 832: return new SocketException(msg); > 833: } These would be easier to find if you add them close to translateToSocketException. ------------- PR: https://git.openjdk.org/jdk/pull/11948 From pminborg at openjdk.org Thu Jan 12 09:02:48 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 12 Jan 2023 09:02:48 GMT Subject: RFR: 8299976: Initialize static fields in Net eagerly [v2] In-Reply-To: References: Message-ID: > This PR proposes initializing some static fields eagerly using `final` fields. > > This will improve performance slightly and will allow us to remove two static fields. > > The PR also contains "blessed" variable casing and deduplication of exception creation. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Rename, move and add clarification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11948/files - new: https://git.openjdk.org/jdk/pull/11948/files/956a3170..9c9485f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11948&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11948&range=00-01 Stats: 35 lines in 1 file changed: 4 ins; 4 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/11948.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11948/head:pull/11948 PR: https://git.openjdk.org/jdk/pull/11948 From alanb at openjdk.org Thu Jan 12 10:28:29 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Jan 2023 10:28:29 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v9] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 00:15:45 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Remove spurious file The test looks much better now but I think can be improved a bit more. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 28: > 26: import org.junit.jupiter.api.Assertions; > 27: import org.junit.jupiter.params.ParameterizedTest; > 28: import org.junit.jupiter.params.provider.ValueSource; Up to you but in other tests, we import static org.junit.jupiter.api.Assertions.* so that the asserts are simple assertXXX calls. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 36: > 34: * IllegalArgumentException if the capacity is negative or greater than > 35: * Integer::MAX_VALUE > 36: * @requires (sun.arch.data.model == "64" & os.maxMemory >= 8g) The @summary should probably be updated to say that it's a unit test for JNI NewDirectBufferBuffer. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 53: > 51: "Buffer::position returned unexpected value"); > 52: Assertions.assertEquals(capacity, buf.limit(), > 53: "Buffer::limit returned unexpected value"); For completeness, I think checkBuffer should also set/get some elements. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 77: > 75: } > 76: } catch (OutOfMemoryError ignored) { > 77: // Ignore the error If I read this correctly, this frees the backing memory before it tests the buffer methods. This may be safe because checkBuffer doesn't access the buffer contents but if the checks are expanded then this will crash. I think you should be able to reduce this method down to this: ByteBuffer buf = newDirectByteBuffer(capacity); try { checkBuffer(buf, capacity); } finally { freeDirectByteBufferMemory(buf); } test/jdk/java/nio/jni/NewDirectByteBuffer.java line 83: > 81: @ParameterizedTest > 82: @ValueSource(longs = {Long.MIN_VALUE, (long)Integer.MIN_VALUE - 1L, -1L, > 83: (long)Integer.MAX_VALUE + 1L, 3_000_000_000L, 5_000_000_000L, Just curious why 3_000_000_000L and 5_000_000_000L are in the values to test. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 93: > 91: } > 92: }); > 93: } catch (OutOfMemoryError ignored) { Why is there is catch of OOME here? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 12 19:41:49 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Jan 2023 19:41:49 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v10] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Miscellaneous cleanup of unit test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/5269cae1..2fe819ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=08-09 Stats: 69 lines in 1 file changed: 46 ins; 14 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 12 19:48:59 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Jan 2023 19:48:59 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v11] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Remove unneeded OutOfMemoryError catch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/2fe819ba..38ea7997 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=09-10 Stats: 9 lines in 1 file changed: 1 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 12 19:49:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Jan 2023 19:49:06 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v9] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 10:17:04 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Remove spurious file > > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 28: > >> 26: import org.junit.jupiter.api.Assertions; >> 27: import org.junit.jupiter.params.ParameterizedTest; >> 28: import org.junit.jupiter.params.provider.ValueSource; > > Up to you but in other tests, we import static org.junit.jupiter.api.Assertions.* so that the asserts are simple assertXXX calls. Fixed in 2fe819ba1fd929eaaa6cc31caee38e217006c3f0. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 36: > >> 34: * IllegalArgumentException if the capacity is negative or greater than >> 35: * Integer::MAX_VALUE >> 36: * @requires (sun.arch.data.model == "64" & os.maxMemory >= 8g) > > The @summary should probably be updated to say that it's a unit test for JNI NewDirectBufferBuffer. So changed in 2fe819ba1fd929eaaa6cc31caee38e217006c3f0. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 53: > >> 51: "Buffer::position returned unexpected value"); >> 52: Assertions.assertEquals(capacity, buf.limit(), >> 53: "Buffer::limit returned unexpected value"); > > For completeness, I think checkBuffer should also set/get some elements. Tests added in 2fe819ba1fd929eaaa6cc31caee38e217006c3f0. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 77: > >> 75: } >> 76: } catch (OutOfMemoryError ignored) { >> 77: // Ignore the error > > If I read this correctly, this frees the backing memory before it tests the buffer methods. This may be safe because checkBuffer doesn't access the buffer contents but if the checks are expanded then this will crash. > > I think you should be able to reduce this method down to this: > > > ByteBuffer buf = newDirectByteBuffer(capacity); > try { > checkBuffer(buf, capacity); > } finally { > freeDirectByteBufferMemory(buf); > } So changed in 2fe819ba1fd929eaaa6cc31caee38e217006c3f0. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 83: > >> 81: @ParameterizedTest >> 82: @ValueSource(longs = {Long.MIN_VALUE, (long)Integer.MIN_VALUE - 1L, -1L, >> 83: (long)Integer.MAX_VALUE + 1L, 3_000_000_000L, 5_000_000_000L, > > Just curious why 3_000_000_000L and 5_000_000_000L are in the values to test. They were in the initial bug report. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 93: > >> 91: } >> 92: }); >> 93: } catch (OutOfMemoryError ignored) { > > Why is there is catch of OOME here? Apparently it is not needed so removed in 38ea7997be2be59e2cea97c7dabf929210c0edfa. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Thu Jan 12 20:08:29 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Jan 2023 20:08:29 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v11] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 19:48:59 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Remove unneeded OutOfMemoryError catch I think this looks okay. If you are doing any further edits then the try-finally OOME can be removed from the illegalCapacities test. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 12 20:28:56 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Jan 2023 20:28:56 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v12] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Removed try-finally OOME from the illegalCapacities test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/38ea7997..7d526352 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=10-11 Stats: 10 lines in 1 file changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Thu Jan 12 20:34:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Jan 2023 20:34:22 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v12] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 20:28:56 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Removed try-finally OOME from the illegalCapacities test Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Fri Jan 13 12:21:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 13 Jan 2023 12:21:16 GMT Subject: RFR: 8299976: Initialize static fields in Net eagerly [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 09:02:48 GMT, Per Minborg wrote: >> This PR proposes initializing some static fields eagerly using `final` fields. >> >> This will improve performance slightly and will allow us to remove two static fields. >> >> The PR also contains "blessed" variable casing and deduplication of exception creation. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Rename, move and add clarification Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11948 From pminborg at openjdk.org Fri Jan 13 15:23:05 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 13 Jan 2023 15:23:05 GMT Subject: Integrated: 8299976: Initialize static fields in Net eagerly In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 15:01:54 GMT, Per Minborg wrote: > This PR proposes initializing some static fields eagerly using `final` fields. > > This will improve performance slightly and will allow us to remove two static fields. > > The PR also contains "blessed" variable casing and deduplication of exception creation. This pull request has now been integrated. Changeset: ce1193a1 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/ce1193a1edb3cdf20f9448ccbbfb053c2418074a Stats: 98 lines in 1 file changed: 13 ins; 15 del; 70 mod 8299976: Initialize static fields in Net eagerly Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/11948 From dholmes at openjdk.org Mon Jan 16 00:42:13 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 00:42:13 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v9] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 19:44:08 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/jni/NewDirectByteBuffer.java line 93: >> >>> 91: } >>> 92: }); >>> 93: } catch (OutOfMemoryError ignored) { >> >> Why is there is catch of OOME here? > > Apparently it is not needed so removed in 38ea7997be2be59e2cea97c7dabf929210c0edfa. No wonder I couldn't find this change! The catch of OOME was added because I still believe that trying to allocate a buffer of capacity Integer.MAX_VALUE will throw OOME (at least some of the time). If that happens then the test should not fail. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Mon Jan 16 08:22:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 16 Jan 2023 08:22:15 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v9] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 00:39:33 GMT, David Holmes wrote: >> Apparently it is not needed so removed in 38ea7997be2be59e2cea97c7dabf929210c0edfa. > > No wonder I couldn't find this change! The catch of OOME was added because I still believe that trying to allocate a buffer of capacity Integer.MAX_VALUE will throw OOME (at least some of the time). If that happens then the test should not fail. No objection to having the test pass if malloc fails but it would be better if the native newDirectByteBuffer were changed to just call JNI NewDirectByteBuffer with a given address so that the malloc + JNI function aren't in the same native method. That allows the test to distinguish malloc returning NULl from NewDirectByteBuffer throwing OOME. The native method freeDirectByteBufferMemory can be split too so that there is native method get the direct buffer address. With these changes, the test can use Unsafe allocateMemory/freeMemory (changing to FFM APIs in the future) or have native methods that do the malloc/free. The more basic methods means the test can be improved, e.g. checkBuffer doesn't currently test that GetDirectBufferAddress returns the address that the DBB was created to wrap. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 18 03:15:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Jan 2023 03:15:53 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v13] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Split native methods; use Unsafe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/7d526352..abc6b586 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=11-12 Stats: 37 lines in 2 files changed: 9 ins; 15 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 18 03:17:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Jan 2023 03:17:53 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v14] In-Reply-To: References: Message-ID: <1b3G5rQeMqfO1YyuB1oOylhjz6s0Un-pwDaXrZYZAt8=.e22dc3f0-621e-43fc-b3b8-651bfdcb6a2b@github.com> > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Clean up memory deallocation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/abc6b586..3b64bd20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=12-13 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Wed Jan 18 09:15:34 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Jan 2023 09:15:34 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v14] In-Reply-To: <1b3G5rQeMqfO1YyuB1oOylhjz6s0Un-pwDaXrZYZAt8=.e22dc3f0-621e-43fc-b3b8-651bfdcb6a2b@github.com> References: <1b3G5rQeMqfO1YyuB1oOylhjz6s0Un-pwDaXrZYZAt8=.e22dc3f0-621e-43fc-b3b8-651bfdcb6a2b@github.com> Message-ID: On Wed, 18 Jan 2023 03:17:53 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Clean up memory deallocation test/jdk/java/nio/jni/NewDirectByteBuffer.java line 106: > 104: (long)Integer.MAX_VALUE - 1, (long)Integer.MAX_VALUE}) > 105: void legalCapacities(long capacity) { > 106: long addr = UNSAFE.allocateMemory(capacity); I think David was asking for the test to continue when malloc fails. Now that the test is changed to use Unsafe.allocateMemory it means it has to catch OOME. test/jdk/java/nio/jni/libNewDirectByteBuffer.c line 49: > 47: (JNIEnv *env, jclass cls, jobject buf) > 48: { > 49: return (jlong)(*env)->GetDirectBufferAddress(env, buf); The cast to jlong should be okay for 64-bit. For 32-bit then it will likely need a double cast, as in ((jlong)(int)( .. )) but maybe okay for now as you've restricted the test to 64-bit. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 18 16:58:54 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Jan 2023 16:58:54 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v14] In-Reply-To: References: <1b3G5rQeMqfO1YyuB1oOylhjz6s0Un-pwDaXrZYZAt8=.e22dc3f0-621e-43fc-b3b8-651bfdcb6a2b@github.com> Message-ID: On Wed, 18 Jan 2023 09:07:06 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Clean up memory deallocation > > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 106: > >> 104: (long)Integer.MAX_VALUE - 1, (long)Integer.MAX_VALUE}) >> 105: void legalCapacities(long capacity) { >> 106: long addr = UNSAFE.allocateMemory(capacity); > > I think David was asking for the test to continue when malloc fails. Now that the test is changed to use Unsafe.allocateMemory it means it has to catch OOME. Added catch of OOME in f9350695c3a6f90e3acdf2176d78c06406e49387. > test/jdk/java/nio/jni/libNewDirectByteBuffer.c line 49: > >> 47: (JNIEnv *env, jclass cls, jobject buf) >> 48: { >> 49: return (jlong)(*env)->GetDirectBufferAddress(env, buf); > > The cast to jlong should be okay for 64-bit. For 32-bit then it will likely need a double cast, as in ((jlong)(int)( .. )) but maybe okay for now as you've restricted the test to 64-bit. Leaving it as-is for now. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 18 16:58:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Jan 2023 16:58:53 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v15] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Catch OOME from Unsafe::allocateMemory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/3b64bd20..f9350695 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=13-14 Stats: 19 lines in 1 file changed: 8 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 18 17:17:44 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Jan 2023 17:17:44 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v16] In-Reply-To: References: Message-ID: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Further cleanup around handling OOME (or not) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/f9350695..040374bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=14-15 Stats: 29 lines in 1 file changed: 13 ins; 12 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Wed Jan 18 17:30:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Jan 2023 17:30:21 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v16] In-Reply-To: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> References: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> Message-ID: On Wed, 18 Jan 2023 17:17:44 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Further cleanup around handling OOME (or not) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11873 From duke at openjdk.org Wed Jan 18 17:44:18 2023 From: duke at openjdk.org (Markus KARG) Date: Wed, 18 Jan 2023 17:44:18 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v17] In-Reply-To: References: <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com> Message-ID: <6eTHZpqy9Si807mQkn_X-3nwlkoiPiWWAJePlpWXqYQ=.9fe1cbae-af14-4acd-9419-54000025ed9c@github.com> On Mon, 12 Dec 2022 20:04:40 GMT, Alan Bateman wrote: >> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> Implementing 8278268 >> >> Signed-off-by: Markus Karg > > Which platform was used to generate the performance data? Also what was the source stream? Just asking as FileChannel.transferFrom uses copy_file_range for file-to-file (Linux), memory mapping for file-to-file, and a copy loop for other cases. > > In any case, the changes to ChannelInputStream.transferTo does the right thing. Most of the change in the PR is the tests. I don't have time to look at those closely right now but Lance or Brian might have cycles. @AlanBateman Kindly requesting to continue this review. ------------- PR: https://git.openjdk.org/jdk/pull/6711 From dholmes at openjdk.org Thu Jan 19 07:45:36 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 07:45:36 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v16] In-Reply-To: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> References: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> Message-ID: <_9HNX36UyNqea-82du1juKCEGv5T8StcAGScA-T8S-Y=.baec0d25-e7b0-495a-a840-b8d5486c569f@github.com> On Wed, 18 Jan 2023 17:17:44 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Further cleanup around handling OOME (or not) test/jdk/java/nio/jni/NewDirectByteBuffer.java line 130: > 128: void illegalCapacities(long capacity) { > 129: assertThrows(IllegalArgumentException.class, () -> { > 130: long addr = UNSAFE.allocateMemory(capacity); How is `allocateMemory` going to respond to these illegal capacity requests? If we expect `newDirectByteBuffer` to throw then can't we use a dummy buffer value as it will never be used? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Thu Jan 19 07:56:32 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 19 Jan 2023 07:56:32 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v16] In-Reply-To: <_9HNX36UyNqea-82du1juKCEGv5T8StcAGScA-T8S-Y=.baec0d25-e7b0-495a-a840-b8d5486c569f@github.com> References: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> <_9HNX36UyNqea-82du1juKCEGv5T8StcAGScA-T8S-Y=.baec0d25-e7b0-495a-a840-b8d5486c569f@github.com> Message-ID: On Thu, 19 Jan 2023 07:42:54 GMT, David Holmes wrote: > How is `allocateMemory` going to respond to these illegal capacity requests? > > If we expect `newDirectByteBuffer` to throw then can't we use a dummy buffer value as it will never be used? For illegalCapacities it should call allocateMemory with some fixed value, say 1, not capacity. Surprised the allocateMemory isn't failing for the test inputs. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From redestad at openjdk.org Thu Jan 19 11:53:12 2023 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 19 Jan 2023 11:53:12 GMT Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base Message-ID: Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that. After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base. ------------- Commit messages: - Miscellaneous hashCode improvements in java.base Changes: https://git.openjdk.org/jdk/pull/12093/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12093&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300647 Stats: 44 lines in 3 files changed: 3 ins; 33 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/12093.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12093/head:pull/12093 PR: https://git.openjdk.org/jdk/pull/12093 From redestad at openjdk.org Thu Jan 19 13:46:26 2023 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 19 Jan 2023 13:46:26 GMT Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base [v2] In-Reply-To: References: Message-ID: > Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that. > > After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Revert ZipFileSystem changes since it's additionally built as a library dependency and can't rely on jdk.internal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12093/files - new: https://git.openjdk.org/jdk/pull/12093/files/5f36ebd7..b1507e69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12093&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12093&range=00-01 Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12093.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12093/head:pull/12093 PR: https://git.openjdk.org/jdk/pull/12093 From duke at openjdk.org Thu Jan 19 14:15:40 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 19 Jan 2023 14:15:40 GMT Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 13:46:26 GMT, Claes Redestad wrote: >> Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that. >> >> After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Revert ZipFileSystem changes since it's additionally built as a library dependency and can't rely on jdk.internal src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 415: > 413: } > 414: > 415: // Replace with general purpose method someday @cl4es Nice work addressing this 16+ year old comment! ? ------------- PR: https://git.openjdk.org/jdk/pull/12093 From stsypanov at openjdk.org Thu Jan 19 15:11:16 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Thu, 19 Jan 2023 15:11:16 GMT Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 13:46:26 GMT, Claes Redestad wrote: >> Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that. >> >> After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Revert ZipFileSystem changes since it's additionally built as a library dependency and can't rely on jdk.internal Marked as reviewed by stsypanov (Author). ------------- PR: https://git.openjdk.org/jdk/pull/12093 From rriggs at openjdk.org Thu Jan 19 15:29:04 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 19 Jan 2023 15:29:04 GMT Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 13:46:26 GMT, Claes Redestad wrote: >> Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that. >> >> After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Revert ZipFileSystem changes since it's additionally built as a library dependency and can't rely on jdk.internal Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12093 From redestad at openjdk.org Thu Jan 19 16:53:22 2023 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 19 Jan 2023 16:53:22 GMT Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 13:46:26 GMT, Claes Redestad wrote: >> Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that. >> >> After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Revert ZipFileSystem changes since it's additionally built as a library dependency and can't rely on jdk.internal Thanks for reviewing! ------------- PR: https://git.openjdk.org/jdk/pull/12093 From redestad at openjdk.org Thu Jan 19 16:53:24 2023 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 19 Jan 2023 16:53:24 GMT Subject: Integrated: 8300647: Miscellaneous hashCode improvements in java.base In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 11:45:12 GMT, Claes Redestad wrote: > Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that. > > After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base. This pull request has now been integrated. Changeset: d85243f0 Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/d85243f02b34d03bd7af63a5bcbc73f500f720df Stats: 37 lines in 2 files changed: 1 ins; 31 del; 5 mod 8300647: Miscellaneous hashCode improvements in java.base Reviewed-by: stsypanov, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/12093 From bpb at openjdk.org Fri Jan 20 17:26:23 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Jan 2023 17:26:23 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v17] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Allocate buffer of fixed size unity in illegalCapacities() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/040374bc..3b1eef25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Fri Jan 20 17:26:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Jan 2023 17:26:25 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v16] In-Reply-To: References: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> <_9HNX36UyNqea-82du1juKCEGv5T8StcAGScA-T8S-Y=.baec0d25-e7b0-495a-a840-b8d5486c569f@github.com> Message-ID: On Thu, 19 Jan 2023 07:53:15 GMT, Alan Bateman wrote: >> test/jdk/java/nio/jni/NewDirectByteBuffer.java line 130: >> >>> 128: void illegalCapacities(long capacity) { >>> 129: assertThrows(IllegalArgumentException.class, () -> { >>> 130: long addr = UNSAFE.allocateMemory(capacity); >> >> How is `allocateMemory` going to respond to these illegal capacity requests? >> >> If we expect `newDirectByteBuffer` to throw then can't we use a dummy buffer value as it will never be used? > >> How is `allocateMemory` going to respond to these illegal capacity requests? >> >> If we expect `newDirectByteBuffer` to throw then can't we use a dummy buffer value as it will never be used? > > For illegalCapacities it should call allocateMemory with some fixed value, say 1, not capacity. Surprised the allocateMemory isn't failing for the test inputs. Changed allocation size to `1` in `illegalCapacities` in 3b1eef25b53dbeb36e4b3a8d6c279a5e0f5a5ae3. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Fri Jan 20 19:57:35 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Jan 2023 19:57:35 GMT Subject: RFR: 8300587: (bf) Some covariant overrides are missing @since tags Message-ID: Reinstate `@since 9` tags for `MappedByteBuffer` and `$TypeBuffer` covariant overrides. ------------- Commit messages: - 8300587: (bf) Some covariant overrides are missing @since tags Changes: https://git.openjdk.org/jdk/pull/12123/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12123&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300587 Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12123/head:pull/12123 PR: https://git.openjdk.org/jdk/pull/12123 From alanb at openjdk.org Fri Jan 20 20:01:47 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 20 Jan 2023 20:01:47 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v17] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 17:26:23 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Allocate buffer of fixed size unity in illegalCapacities() Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11873 From lancea at openjdk.org Fri Jan 20 20:11:44 2023 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 20 Jan 2023 20:11:44 GMT Subject: RFR: 8300587: (bf) Some covariant overrides are missing @since tags In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 19:29:01 GMT, Brian Burkhalter wrote: > Reinstate `@since 9` tags for `MappedByteBuffer` and `$TypeBuffer` covariant overrides. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12123 From bpb at openjdk.org Fri Jan 20 21:24:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Jan 2023 21:24:53 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value [v3] In-Reply-To: References: Message-ID: > Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension. 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 - 8297814: Address reviewer comments - 8297814: (fs) Re-visit Path.getExtension return value ------------- Changes: https://git.openjdk.org/jdk/pull/11545/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11545&range=02 Stats: 149 lines in 2 files changed: 148 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11545.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11545/head:pull/11545 PR: https://git.openjdk.org/jdk/pull/11545 From iris at openjdk.org Fri Jan 20 21:48:08 2023 From: iris at openjdk.org (Iris Clark) Date: Fri, 20 Jan 2023 21:48:08 GMT Subject: RFR: 8300587: (bf) Some covariant overrides are missing @since tags In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 19:29:01 GMT, Brian Burkhalter wrote: > Reinstate `@since 9` tags for `MappedByteBuffer` and `$TypeBuffer` covariant overrides. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12123 From dholmes at openjdk.org Sun Jan 22 22:21:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 22 Jan 2023 22:21:08 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v17] In-Reply-To: References: Message-ID: <_um7aUkLXTtU4kDpDy9l6Z_Pdn3ls7-KPAjzpzlZAVE=.df3935e3-f11d-452b-83cf-52e15a09c669@github.com> On Fri, 20 Jan 2023 17:26:23 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Allocate buffer of fixed size unity in illegalCapacities() Nothing further from me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Mon Jan 23 17:14:51 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 23 Jan 2023 17:14:51 GMT Subject: Integrated: 8300587: (bf) Some covariant overrides are missing @since tags In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 19:29:01 GMT, Brian Burkhalter wrote: > Reinstate `@since 9` tags for `MappedByteBuffer` and `$TypeBuffer` covariant overrides. This pull request has now been integrated. Changeset: 542bfe61 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/542bfe61e67b72bebff45e7382ec3f40bdab9aae Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod 8300587: (bf) Some covariant overrides are missing @since tags Reviewed-by: lancea, iris ------------- PR: https://git.openjdk.org/jdk/pull/12123 From bpb at openjdk.org Mon Jan 23 17:22:39 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 23 Jan 2023 17:22:39 GMT Subject: Integrated: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 22:25:19 GMT, Brian Burkhalter wrote: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. This pull request has now been integrated. Changeset: a56598f5 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/a56598f5a534cc9223367e7faa8433ea38661db9 Stats: 221 lines in 5 files changed: 212 ins; 3 del; 6 mod 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.org/jdk/pull/11873 From iklam at openjdk.org Tue Jan 24 00:25:21 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 24 Jan 2023 00:25:21 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v17] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 17:26:23 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Allocate buffer of fixed size unity in illegalCapacities() This PR is causing causing x86 build failures in GitHub actions. I filed https://bugs.openjdk.org/browse/JDK-8300942 ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Tue Jan 24 02:44:16 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 24 Jan 2023 02:44:16 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v17] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 00:22:20 GMT, Ioi Lam wrote: > This PR is causing causing x86 build failures in GitHub actions. I filed https://bugs.openjdk.org/browse/JDK-8300942 PR #12157 has been created to address this problem. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Tue Jan 24 02:46:36 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 24 Jan 2023 02:46:36 GMT Subject: RFR: 8300942: JDK-8299684 breaks x86 build Message-ID: Fix the build on x86. ------------- Commit messages: - 8300942: JDK-8299684 breaks x86 build Changes: https://git.openjdk.org/jdk/pull/12157/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12157&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300942 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12157.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12157/head:pull/12157 PR: https://git.openjdk.org/jdk/pull/12157 From bpb at openjdk.org Tue Jan 24 02:46:36 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 24 Jan 2023 02:46:36 GMT Subject: RFR: 8300942: JDK-8299684 breaks x86 build In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 02:38:29 GMT, Brian Burkhalter wrote: > Fix the build on x86. With this change applied the `linux-x86` build target now succeeds and the 64-platform builds and test results are unaffected. ------------- PR: https://git.openjdk.org/jdk/pull/12157 From dholmes at openjdk.org Tue Jan 24 06:54:03 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 06:54:03 GMT Subject: RFR: 8300942: JDK-8299684 breaks x86 build In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 02:38:29 GMT, Brian Burkhalter wrote: > Fix the build on x86. Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12157 From dholmes at openjdk.org Tue Jan 24 06:54:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 06:54:14 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v14] In-Reply-To: References: <1b3G5rQeMqfO1YyuB1oOylhjz6s0Un-pwDaXrZYZAt8=.e22dc3f0-621e-43fc-b3b8-651bfdcb6a2b@github.com> Message-ID: On Wed, 18 Jan 2023 16:54:45 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/jni/libNewDirectByteBuffer.c line 49: >> >>> 47: (JNIEnv *env, jclass cls, jobject buf) >>> 48: { >>> 49: return (jlong)(*env)->GetDirectBufferAddress(env, buf); >> >> The cast to jlong should be okay for 64-bit. For 32-bit then it will likely need a double cast, as in ((jlong)(int)( .. )) but maybe okay for now as you've restricted the test to 64-bit. > > Leaving it as-is for now. FTR this was the wrong choice as the test is still built on 32-bit (and fails to compile). ------------- PR: https://git.openjdk.org/jdk/pull/11873 From jiefu at openjdk.org Tue Jan 24 11:17:04 2023 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 24 Jan 2023 11:17:04 GMT Subject: RFR: 8300942: JDK-8299684 breaks x86 build In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 02:38:29 GMT, Brian Burkhalter wrote: > Fix the build on x86. This bug was not caught with gcc 7.5.0, but https://github.com/openjdk/jdk/pull/12165 was exposed. ------------- PR: https://git.openjdk.org/jdk/pull/12157 From jiefu at openjdk.org Tue Jan 24 11:27:03 2023 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 24 Jan 2023 11:27:03 GMT Subject: RFR: 8300942: JDK-8299684 breaks x86 build In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 02:38:29 GMT, Brian Burkhalter wrote: > Fix the build on x86. Marked as reviewed by jiefu (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12157 From bpb at openjdk.org Tue Jan 24 20:36:14 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 24 Jan 2023 20:36:14 GMT Subject: Integrated: 8300942: JDK-8299684 breaks x86 build In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 02:38:29 GMT, Brian Burkhalter wrote: > Fix the build on x86. This pull request has now been integrated. Changeset: b678e700 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/b678e70003cc2c84df426bb63a07f43e508604bf Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8300942: JDK-8299684 breaks x86 build Reviewed-by: dholmes, jiefu ------------- PR: https://git.openjdk.org/jdk/pull/12157 From bpb at openjdk.org Tue Jan 24 22:18:45 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 24 Jan 2023 22:18:45 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) Message-ID: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. ------------- Commit messages: - 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) Changes: https://git.openjdk.org/jdk/pull/12174/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12174&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299982 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12174.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12174/head:pull/12174 PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Tue Jan 24 22:18:45 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 24 Jan 2023 22:18:45 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) In-Reply-To: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Tue, 24 Jan 2023 22:07:51 GMT, Brian Burkhalter wrote: > Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. Using a microbenchmark derived from the one in [panama-foreign PR 762](https://github.com/openjdk/panama-foreign/pull/762), the following changes in average execution times were observed for `ByteBuffer::getLong` and `ByteBuffer::putLong`. **Throughput of `ByteBuffer::getLong(int)` in ns/op** | size | before | after | |------|--------|-------| | 1 | 7.532 | 6.034 | | 2 |8.288 | 6.580 | | 16 | 15.591 | 12.902 | | 64 |34.704 | 28.589 | | 256 | 109.651 | 82.341 | **Throughput of `ByteBuffer::putLong(int, long)` in ns/op** | size | before | after | |------|--------|-------| | 1 | 4.863 | 3.605 | | 2 | 5.730 | 4.247 | | 16 | 13.784 | 10.004 | | 64 | 32.956 | 26.201 | | 256 | 144.046 | 80.822 | ------------- PR: https://git.openjdk.org/jdk/pull/12174 From uschindler at openjdk.org Tue Jan 24 23:36:02 2023 From: uschindler at openjdk.org (Uwe Schindler) Date: Tue, 24 Jan 2023 23:36:02 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) In-Reply-To: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Tue, 24 Jan 2023 22:07:51 GMT, Brian Burkhalter wrote: > Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. Marked as reviewed by uschindler (Author). Looks fine to me. Benchmarks look fine. We were already wondering why ByteBuffer behaved not so well in the Panama benchmark. ------------- PR: https://git.openjdk.org/jdk/pull/12174 From vtewari at openjdk.org Wed Jan 25 06:14:05 2023 From: vtewari at openjdk.org (Vyom Tewari) Date: Wed, 25 Jan 2023 06:14:05 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) In-Reply-To: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: <85hCTuECsb9rWhJ78kTqctIcf0DFS-KNT2fzCg1eEy0=.df781686-505b-4400-beb2-8c0a2a4d4ac2@github.com> On Tue, 24 Jan 2023 22:07:51 GMT, Brian Burkhalter wrote: > Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. Looks OK to me. ------------- Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.org/jdk/pull/12174 From stsypanov at openjdk.org Wed Jan 25 08:59:04 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Wed, 25 Jan 2023 08:59:04 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) In-Reply-To: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Tue, 24 Jan 2023 22:07:51 GMT, Brian Burkhalter wrote: > Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. > size | before | after -- | -- | -- 1 | 4.863 | 3.605 Why does it make such a significant difference? Intrinsic? ------------- PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Wed Jan 25 16:52:54 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 25 Jan 2023 16:52:54 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Wed, 25 Jan 2023 08:55:58 GMT, Sergey Tsypanov wrote: > Why does it make such a significant difference? Intrinsic? Yes. `Objects::checkIndex`: @ForceInline public static int checkIndex(int index, int length) { return Preconditions.checkIndex(index, length, null); } `Preconditions.checkIndex`: @IntrinsicCandidate public static int checkIndex(int index, int length, BiFunction, X> oobef) {...} ------------- PR: https://git.openjdk.org/jdk/pull/12174 From alanb at openjdk.org Wed Jan 25 17:55:42 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 25 Jan 2023 17:55:42 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) In-Reply-To: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Tue, 24 Jan 2023 22:07:51 GMT, Brian Burkhalter wrote: > Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. The number of byte parameter is 1, 2, 4 or 8 so limit - nb + 1 shouldn't overflow. I'm just mulling over the exception messages, e.g. `ByteBuffer.allocate(0).getChar(0)` will throw `java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length -1`. ------------- PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Wed Jan 25 17:59:42 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 25 Jan 2023 17:59:42 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Wed, 25 Jan 2023 17:53:09 GMT, Alan Bateman wrote: > I'm just mulling over the exception messages Presently there is no exception message so no one can be relying on it. ------------- PR: https://git.openjdk.org/jdk/pull/12174 From alanb at openjdk.org Wed Jan 25 18:11:45 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 25 Jan 2023 18:11:45 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Wed, 25 Jan 2023 17:56:31 GMT, Brian Burkhalter wrote: > Presently there is no exception message so no one can be relying on it. I should have been cleaner, I mean the message is confusing. In the example the message includes "for length -1" but that doesn't make any sense here. I suspect we'll need to add a new exception mapper to Preconditions and have checkIndex call the 3-arg Preconditions.checkIndex method. In Buffer, the checkIndex can be @ForceInline so it inlines similar to Objects.checkIndex. ------------- PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Wed Jan 25 20:26:18 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 25 Jan 2023 20:26:18 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) [v2] In-Reply-To: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: > Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299982: Change Objects::checkIndex to Preconditions::checkIndex; improve exception message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12174/files - new: https://git.openjdk.org/jdk/pull/12174/files/c25837f8..24d21cd2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12174&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12174&range=00-01 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12174.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12174/head:pull/12174 PR: https://git.openjdk.org/jdk/pull/12174 From alanb at openjdk.org Wed Jan 25 20:26:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 25 Jan 2023 20:26:18 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) [v2] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Wed, 25 Jan 2023 20:22:19 GMT, Brian Burkhalter wrote: >> Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299982: Change Objects::checkIndex to Preconditions::checkIndex; improve exception message src/java.base/share/classes/java/nio/Buffer.java line 752: > 750: final int checkIndex(int i, int nb) { // package-private > 751: return Preconditions.checkIndex(i, limit - nb + 1, > 752: (x, y) -> { I don't know if you've retested the performance but I think you'll need this parameter to be a constant and checkIndex may need to be ForceInline. While we're here, I think we'll have to check the exception message throw by the 1-arg checkIndex to make sure it make sense for buffers. ------------- PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Wed Jan 25 20:34:00 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 25 Jan 2023 20:34:00 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) [v2] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Wed, 25 Jan 2023 20:22:19 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299982: Change Objects::checkIndex to Preconditions::checkIndex; improve exception message > > src/java.base/share/classes/java/nio/Buffer.java line 752: > >> 750: final int checkIndex(int i, int nb) { // package-private >> 751: return Preconditions.checkIndex(i, limit - nb + 1, >> 752: (x, y) -> { > > I don't know if you've retested the performance but I think you'll need this parameter to be a constant and checkIndex may need to be ForceInline. While we're here, I think we'll have to check the exception message throw by the 1-arg checkIndex to make sure it make sense for buffers. I re-tested with and without ForceInline and see little difference. ------------- PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Wed Jan 25 20:45:37 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 25 Jan 2023 20:45:37 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) [v2] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: <_Nbnb97GwtvD_oig2A56NTCCvtfGcf1eGXsQhmQ5Pqo=.bb626898-936c-4de7-974a-50183e34a03d@github.com> On Wed, 25 Jan 2023 20:26:18 GMT, Brian Burkhalter wrote: >> Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299982: Change Objects::checkIndex to Preconditions::checkIndex; improve exception message Performance using `Preconditions::checkIndex` instead of `Objects::checkIndex`: **Average Execution Time of `ByteBuffer::getLong(int)` in ns/op** | size | before | after | |------|---------|--------| | 1 | 7.728 | 6.277 | | 2 | 8.155 | 6.678 | | 16 | 15.517 | 13.030 | | 64 | 34.818 | 28.673 | | 256 | 110.963 | 83.330 | **Average Execution Time of `ByteBuffer::putLong(int, long)` in ns/op** | size | before | after | |------|---------|--------| | 1 | 4.872 | 3.631 | | 2 | 5.709 | 4.294 | | 16 | 13.828 | 10.093 | | 64 | 330250 | 26.519 | | 256 | 152.409 | 80.466 | ------------- PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Wed Jan 25 20:53:02 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 25 Jan 2023 20:53:02 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) [v3] In-Reply-To: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: > Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299982: Add ForceInline annotation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12174/files - new: https://git.openjdk.org/jdk/pull/12174/files/24d21cd2..4729bd9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12174&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12174&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12174.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12174/head:pull/12174 PR: https://git.openjdk.org/jdk/pull/12174 From rriggs at openjdk.org Wed Jan 25 21:26:44 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 25 Jan 2023 21:26:44 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Objects.checkIndex(int, int) [v3] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Wed, 25 Jan 2023 20:53:02 GMT, Brian Burkhalter wrote: >> Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299982: Add ForceInline annotation Marked as reviewed by rriggs (Reviewer). You may want to update the issue and title to match the change to use Preconditions. Or say it is a generic performance improvement on range checks. ------------- PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Wed Jan 25 21:46:11 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 25 Jan 2023 21:46:11 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) [v3] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Wed, 25 Jan 2023 21:23:30 GMT, Roger Riggs wrote: > You may want to update the issue and title to match the change to use Preconditions. Good idea: done. ------------- PR: https://git.openjdk.org/jdk/pull/12174 From alanb at openjdk.org Thu Jan 26 07:20:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 26 Jan 2023 07:20:49 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) [v2] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Wed, 25 Jan 2023 20:30:55 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/Buffer.java line 752: >> >>> 750: final int checkIndex(int i, int nb) { // package-private >>> 751: return Preconditions.checkIndex(i, limit - nb + 1, >>> 752: (x, y) -> { >> >> I don't know if you've retested the performance but I think you'll need this parameter to be a constant and checkIndex may need to be ForceInline. While we're here, I think we'll have to check the exception message throw by the 1-arg checkIndex to make sure it make sense for buffers. > > I re-tested with and without ForceInline and see little difference. I was hoping the 3rd parameter to Preconditions.checkIndex would be constant. It looks like it's a capturing lambda ("this" is captured because of the access to the position/limit fields). Hmm, maybe start out simple with a constant, otherwise this change is going to require much wider startup and performance testing. ------------- PR: https://git.openjdk.org/jdk/pull/12174 From uschindler at openjdk.org Thu Jan 26 09:49:52 2023 From: uschindler at openjdk.org (Uwe Schindler) Date: Thu, 26 Jan 2023 09:49:52 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) [v2] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Thu, 26 Jan 2023 07:18:02 GMT, Alan Bateman wrote: >> I re-tested with and without ForceInline and see little difference. > > I was hoping the 3rd parameter to Preconditions.checkIndex would be constant. It looks like it's a capturing lambda ("this" is captured because of the access to the position/limit fields). Hmm, maybe start out simple with a constant, otherwise this change is going to require much wider startup and performance testing. In the original code it just has `throw new IndexOutOfBoundsException();`, so why not make it non-capturing lambda by just returning the same, e.g., `(x, y) -> new IndexOutOfBoundsException()` ------------- PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Thu Jan 26 17:51:17 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 26 Jan 2023 17:51:17 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) [v2] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Thu, 26 Jan 2023 09:46:18 GMT, Uwe Schindler wrote: >> I was hoping the 3rd parameter to Preconditions.checkIndex would be constant. It looks like it's a capturing lambda ("this" is captured because of the access to the position/limit fields). Hmm, maybe start out simple with a constant, otherwise this change is going to require much wider startup and performance testing. > > In the original code it just has `throw new IndexOutOfBoundsException();`, so why not make it non-capturing lambda by just returning the same, e.g., `(x, y) -> new IndexOutOfBoundsException()` > Hmm, maybe start out simple with a constant, otherwise this change is going to require much wider startup and performance testing. Something like? @ForceInline final int checkIndex(int i, int nb) { // package-private return Preconditions.checkIndex(i, limit - nb + 1, (x, y) -> new IndexOutOfBoundsException()); } ------------- PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Thu Jan 26 17:51:18 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 26 Jan 2023 17:51:18 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) [v2] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Thu, 26 Jan 2023 17:47:54 GMT, Brian Burkhalter wrote: >> In the original code it just has `throw new IndexOutOfBoundsException();`, so why not make it non-capturing lambda by just returning the same, e.g., `(x, y) -> new IndexOutOfBoundsException()` > >> Hmm, maybe start out simple with a constant, otherwise this change is going to require much wider startup and performance testing. > > Something like? > > @ForceInline > final int checkIndex(int i, int nb) { // package-private > return Preconditions.checkIndex(i, limit - nb + 1, > (x, y) -> new IndexOutOfBoundsException()); > } > In the original code it just has `throw new IndexOutOfBoundsException();`, so why not make it non-capturing lambda by just returning the same, e.g., `(x, y) -> new IndexOutOfBoundsException()` We were trying to improve the message but it looks like it is not worth it. ------------- PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Thu Jan 26 18:52:45 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 26 Jan 2023 18:52:45 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) [v4] In-Reply-To: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: > Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299982: Change exception formatter to a constant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12174/files - new: https://git.openjdk.org/jdk/pull/12174/files/4729bd9f..e4ba7173 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12174&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12174&range=02-03 Stats: 33 lines in 1 file changed: 22 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12174.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12174/head:pull/12174 PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Thu Jan 26 18:52:46 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 26 Jan 2023 18:52:46 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) [v2] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: <8uipBYpDUmhutih2mhz99AjqJhpi33ubLwVi7Ok3FB0=.04af7e7b-1109-4577-bb47-31b4bbc8d946@github.com> On Thu, 26 Jan 2023 17:48:46 GMT, Brian Burkhalter wrote: >>> Hmm, maybe start out simple with a constant, otherwise this change is going to require much wider startup and performance testing. >> >> Something like? >> >> @ForceInline >> final int checkIndex(int i, int nb) { // package-private >> return Preconditions.checkIndex(i, limit - nb + 1, >> (x, y) -> new IndexOutOfBoundsException()); >> } > >> In the original code it just has `throw new IndexOutOfBoundsException();`, so why not make it non-capturing lambda by just returning the same, e.g., `(x, y) -> new IndexOutOfBoundsException()` > > We were trying to improve the message but it looks like it is not worth it. Exception formatter changed to a constant in e4ba71731f806897144a90714a72cdd8516df1d2. ------------- PR: https://git.openjdk.org/jdk/pull/12174 From alanb at openjdk.org Thu Jan 26 20:02:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 26 Jan 2023 20:02:18 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) [v4] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: <3taGEq2Gm5d3-W2u0rIrLk7BCFxZfRPjq-ANp3VCoKo=.c68c6703-7b14-4c50-ba4a-2984c7794158@github.com> On Thu, 26 Jan 2023 18:52:45 GMT, Brian Burkhalter wrote: >> Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299982: Change exception formatter to a constant Latest version looks good. The exception message can be looked at another time and changing the one-arg checkIndex to avoid a confusion message is good too. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Thu Jan 26 20:12:26 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 26 Jan 2023 20:12:26 GMT Subject: RFR: 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) [v4] In-Reply-To: References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Thu, 26 Jan 2023 18:52:45 GMT, Brian Burkhalter wrote: >> Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299982: Change exception formatter to a constant Performance of integrated version **Average Execution Time of `ByteBuffer::getLong(int)` in ns/op** | size | before | after | |------|---------|--------| | 1 | 7.711 | 6.288 | | 2 | 8.473 | 6.854 | | 16 | 16.517 | 13.387 | | 64 | 35.953 | 30.016 | | 256 | 114.647 | 86.018 | **Average Execution Time of `ByteBuffer::putLong(int, long)` in ns/op** | size | before | after | |------|---------|--------| | 1 | 5.074 | 3.734 | | 2 | 5.994 | 4.471 | | 16 | 14.442 | 10.472 | | 64 | 34.382 | 27.297 | | 256 | 150.887 | 84.148 | ------------- PR: https://git.openjdk.org/jdk/pull/12174 From bpb at openjdk.org Thu Jan 26 20:12:28 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 26 Jan 2023 20:12:28 GMT Subject: Integrated: 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) In-Reply-To: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> References: <6zBxcc1ZWHe7n1uoLGSyhbB0d5ID2xiBqZlvC0B4hdM=.9a8fb400-16f6-4eb6-b932-5d6ccb21fd04@github.com> Message-ID: On Tue, 24 Jan 2023 22:07:51 GMT, Brian Burkhalter wrote: > Replace explicit check of indexes in `Buffer::checkIndex(int,int)` with a call to `Objects::checkIndex(int,int)` in order to improve the throughput of other methods which invoke `Buffer::checkIndex(int,int)`. This pull request has now been integrated. Changeset: c4278144 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/c4278144bee667e2565a40f12a2a2c251d6cf3aa Stats: 31 lines in 1 file changed: 24 ins; 2 del; 5 mod 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) Reviewed-by: uschindler, vtewari, rriggs, alanb ------------- PR: https://git.openjdk.org/jdk/pull/12174 From duke at openjdk.org Thu Jan 26 23:58:01 2023 From: duke at openjdk.org (=?UTF-8?B?QWxmb25zb8Ky?= Peterssen) Date: Thu, 26 Jan 2023 23:58:01 GMT Subject: RFR: 8298658: Platform-specific type leaks to platform independent code. Message-ID: This is not a cosmetic change, it enforces the isolation of platform-specific code from the user-facing API. `sun.nio.fs.DefaultFileSystemProvider#instance()` has a platform-specific return type. This makes the platform-independent `java.nio.file.FileSystems.DefaultFileSystemHolder#getDefaultProvider()` have a platform-dependent call e.g. INVOKESTATIC with different signatures. The platform-specific return types were introduced in [JDK-8213406](https://bugs.openjdk.org/browse/JDK-8213406), the common SPI type was used before. There's no reason to leak types to platform-independent code, except for tests, which could just cast. This change is motivated by [Espresso](https://github.com/oracle/graal/tree/master/espresso), a meta-circular, spec-compliant JVM written in Java. Espresso aims to provide a custom Java IO/NIO implementation on top of any vanilla JDK as a viable alternative to the imminent removal of `SecurityManager`. ------------- Commit messages: - Avoid leaking implementation types to platform-independent code. Changes: https://git.openjdk.org/jdk/pull/11674/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11674&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298658 Stats: 8 lines in 4 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11674.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11674/head:pull/11674 PR: https://git.openjdk.org/jdk/pull/11674 From alanb at openjdk.org Fri Jan 27 07:16:17 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 27 Jan 2023 07:16:17 GMT Subject: RFR: 8298658: Platform-specific type leaks to platform independent code. In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 13:37:32 GMT, Alfonso? Peterssen wrote: > This is not a cosmetic change, it enforces the isolation of platform-specific code from the user-facing API. > > `sun.nio.fs.DefaultFileSystemProvider#instance()` has a platform-specific return type. This makes the platform-independent `java.nio.file.FileSystems.DefaultFileSystemHolder#getDefaultProvider()` have a platform-dependent call e.g. INVOKESTATIC with different signatures. > > The platform-specific return types were introduced in [JDK-8213406](https://bugs.openjdk.org/browse/JDK-8213406), the common SPI type was used before. There's no reason to leak types to platform-independent code, except for tests, which could just cast. > > This change is motivated by [Espresso](https://github.com/oracle/graal/tree/master/espresso), a meta-circular, spec-compliant JVM written in Java. Espresso aims to provide a custom Java IO/NIO implementation on top of any vanilla JDK as a viable alternative to the imminent removal of `SecurityManager`. The JBS was resolved as "Incomplete" in December, this is why the bot has added "Issue is not open" in the link. This change has no impact on the JDK but the JBS and/or PR needs to provide more context. Are you combining the classes from several builds and trying to de-duplicate or something else? ------------- PR: https://git.openjdk.org/jdk/pull/11674 From rvansa at azul.com Fri Jan 27 16:05:23 2023 From: rvansa at azul.com (Radim Vansa) Date: Fri, 27 Jan 2023 16:05:23 +0000 Subject: xxxDispatcher not marking FileDescriptors as invalid Message-ID: Hello, I was experimenting with tracking file descriptors for checkpoint & restore [1] and found that in some cases, using FileDispatcherImpl/UnixDispatcher (depending on JDK version) the java.io.FileDescriptor is not closed properly. While the underlying descriptor is closed the `fd` field in the FileDescriptor object is not set [2] to -1 like the regular FileDescriptor.close0() method would do [3]. Is there any special idea behind that, or is this alternate code path present only as an optimization in case where we know that none of the regular handling would be needed? Is there any risk in unsetting the fd field? Thank you Radim Vansa [1] https://github.com/openjdk/crac [2] https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnio/ch/UnixDispatcher.c#L58 [3] https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/io_util_md.c#L152 From Alan.Bateman at oracle.com Fri Jan 27 17:15:54 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Jan 2023 17:15:54 +0000 Subject: xxxDispatcher not marking FileDescriptors as invalid In-Reply-To: References: Message-ID: <3dd4dd30-f5f1-b5ac-6395-dbd62beae468@oracle.com> On 27/01/2023 16:05, Radim Vansa wrote: > Hello, > > I was experimenting with tracking file descriptors for checkpoint & restore [1] and found that in some cases, using FileDispatcherImpl/UnixDispatcher (depending on JDK version) the java.io.FileDescriptor is not closed properly. While the underlying descriptor is closed the `fd` field in the FileDescriptor object is not set [2] to -1 like the regular FileDescriptor.close0() method would do [3]. > > Is there any special idea behind that, or is this alternate code path present only as an optimization in case where we know that none of the regular handling would be needed? Is there any risk in unsetting the fd field? In the java.io APIs, FIS/FOS/RAF define getFD methods so the FileDescriptor can be obtained by applications. This is problematic for a bunch of reasons but for the discussion here, setting it to -1 is needed for the FileDescriptor::valid. Another point is that java.io pre-dates the more robust async close mechanism that is NIO and setting it to -1 helps avoid trying to use a file descriptor that has been closed and/or recycled. In the NIO area, FileDescriptor objects do not leak to applications. The only case where it is necessary to set to -1 is on Windows with sockets and this is because there is no equivalent of dup2 there. Another point here is that FileDescriptors aren't really needed as the channels implementation just need the raw file descriptor or handle. -Alan From duke at openjdk.org Fri Jan 27 18:43:34 2023 From: duke at openjdk.org (duke) Date: Fri, 27 Jan 2023 18:43:34 GMT Subject: Withdrawn: 8296546: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From duke at openjdk.org Mon Jan 30 13:27:19 2023 From: duke at openjdk.org (=?UTF-8?B?QWxmb25zb8Ky?= Peterssen) Date: Mon, 30 Jan 2023 13:27:19 GMT Subject: RFR: 8298658: Platform-specific type leaks to platform independent code. In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 13:37:32 GMT, Alfonso? Peterssen wrote: > This is not a cosmetic change, it enforces the isolation of platform-specific code from the user-facing API. > > `sun.nio.fs.DefaultFileSystemProvider#instance()` has a platform-specific return type. This makes the platform-independent `java.nio.file.FileSystems.DefaultFileSystemHolder#getDefaultProvider()` have a platform-dependent call e.g. INVOKESTATIC with different signatures. > > The platform-specific return types were introduced in [JDK-8213406](https://bugs.openjdk.org/browse/JDK-8213406), the common SPI type was used before. There's no reason to leak types to platform-independent code, except for tests, which could just cast. > > This change is motivated by [Espresso](https://github.com/oracle/graal/tree/master/espresso), a meta-circular, spec-compliant JVM written in Java. Espresso aims to provide a custom Java IO/NIO implementation on top of any vanilla JDK as a viable alternative to the imminent removal of `SecurityManager`. NIO has a very clean separation between platform-dependent FS implementations and user-facing APIs, this is the only pain point we found. Our goal (in Espresso) is to override the platform-dependent FS, not just the apllication FS. ### The issue On different OSs, the method [java.nio.file.FileSystems.DefaultFileSystemHolder#getDefaultProvider()](https://github.com/openjdk/jdk/blob/ebb84ad70d3295d9a429904fcdacdb8ecd1bf434/src/java.base/share/classes/java/nio/file/FileSystems.java#L112-L140) is compiled differently by javac. The difference is on the signature of the call to [sun.nio.fs.DefaultFileSystemProvider#instance()](https://github.com/openjdk/jdk/blob/ebb84ad70d3295d9a429904fcdacdb8ecd1bf434/src/java.base/share/classes/java/nio/file/FileSystems.java#L114) which returns a hard-coded {Linux|Windows|Aix|MacOSX}FileSystemProvider depending on the OS it was compiled on. We'd like to replace the platform FS with a custom one e.g. read-only FS, a FS with restricted access to some specific folder/files..., in-memory FS, or in the context of native-image, a FS that only has access to the resources embedded within the native executable... Overriding the platform FS is more difficult that it should be because of this leak. Changing the [signature](https://github.com/openjdk/jdk/blob/ebb84ad70d3295d9a429904fcdacdb8ecd1bf434/src/java.base/linux/classes/sun/nio/fs/DefaultFileSystemProvider.java#L43) to return a `FileSystemProvider` on all OSs fixes the leak without any down-sides. On a final note, the proposed change is trivial and is not meant to enable some dark feature alien to OpenJDK. The change enforces a clean separation between NIO platform-independent code and platform-dependent FS implementations. ------------- PR: https://git.openjdk.org/jdk/pull/11674 From alanb at openjdk.org Mon Jan 30 18:13:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 30 Jan 2023 18:13:22 GMT Subject: RFR: 8298658: Platform-specific type leaks to platform independent code. In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 13:24:13 GMT, Alfonso? Peterssen wrote: > NIO has a very clean separation between platform-dependent FS implementations and user-facing APIs, this is the only pain point we found. > > Our goal (in Espresso) is to override the platform-dependent FS, not just the apllication FS. BTW: Have you looked at the system property "java.nio.file.spi.DefaultFileSystemProvider" as that can be used to specify an alternative implementation of the default provider. ------------- PR: https://git.openjdk.org/jdk/pull/11674 From duke at openjdk.org Tue Jan 31 13:53:57 2023 From: duke at openjdk.org (=?UTF-8?B?QWxmb25zb8Ky?= Peterssen) Date: Tue, 31 Jan 2023 13:53:57 GMT Subject: RFR: 8298658: Platform-specific type leaks to platform independent code. In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 13:37:32 GMT, Alfonso? Peterssen wrote: > This is not a cosmetic change, it enforces the isolation of platform-specific code from the user-facing API. > > `sun.nio.fs.DefaultFileSystemProvider#instance()` has a platform-specific return type. This makes the platform-independent `java.nio.file.FileSystems.DefaultFileSystemHolder#getDefaultProvider()` have a platform-dependent call e.g. INVOKESTATIC with different signatures. > > The platform-specific return types were introduced in [JDK-8213406](https://bugs.openjdk.org/browse/JDK-8213406), the common SPI type was used before. There's no reason to leak types to platform-independent code, except for tests, which could just cast. > > This change is motivated by [Espresso](https://github.com/oracle/graal/tree/master/espresso), a meta-circular, spec-compliant JVM written in Java. Espresso aims to provide a custom Java IO/NIO implementation on top of any vanilla JDK as a viable alternative to the imminent removal of `SecurityManager`. "java.nio.file.spi.DefaultFileSystemProvider" is an application level option, we aim to virtualize the IO for the whole VM. We've already virtualized legacy `java.io` APIs and most of NIO, thanks to the clean separation of platform-dependent code. "Virtualize" here means re-implementing the Java APIs against Truffle APIs. Once the SecurityManager is gone, Espresso could be a viable alternative. ------------- PR: https://git.openjdk.org/jdk/pull/11674 From alanb at openjdk.org Tue Jan 31 15:43:01 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 31 Jan 2023 15:43:01 GMT Subject: RFR: 8298658: Platform-specific type leaks to platform independent code. In-Reply-To: References: Message-ID: <8MADKmXnHU_KzpeQwXL_mb5UOE5avPpkQOiFyZx684o=.771ca975-4b51-450a-9396-98f43ba792e4@github.com> On Tue, 31 Jan 2023 13:50:54 GMT, Alfonso? Peterssen wrote: > "java.nio.file.spi.DefaultFileSystemProvider" is an application level option It is to allow the default file system provider be replaced, or to interpose on the default provider. I have no objection to the changes in the PR but I am concerned that this is a downstream project creating a dependency on JDK code that could change at any time. ------------- PR: https://git.openjdk.org/jdk/pull/11674 From bhuang at openjdk.org Tue Jan 31 19:26:42 2023 From: bhuang at openjdk.org (Bill Huang) Date: Tue, 31 Jan 2023 19:26:42 GMT Subject: RFR: JDK-8300912: Update java/nio/MappedByteBuffer/PmemTest.java to run on x86_64 only Message-ID: This task is created to update jtreg test to run on x86 only because pmem emulation is only supported on x86. For other architectures with external NVRAM, run test with java PmemTest. ------------- Commit messages: - JDK-8300912 Update java/nio/MappedByteBuffer/PmemTest.java to run on x86_64 only Changes: https://git.openjdk.org/jdk/pull/12352/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12352&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300912 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12352.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12352/head:pull/12352 PR: https://git.openjdk.org/jdk/pull/12352 From alanb at openjdk.org Tue Jan 31 20:42:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 31 Jan 2023 20:42:50 GMT Subject: RFR: JDK-8300912: Update java/nio/MappedByteBuffer/PmemTest.java to run on x86_64 only In-Reply-To: References: Message-ID: <5Y-l74ZQl-HHVYlRIjGRQo7DmGxsFnzK6GovUJNIl_g=.ebf91943-3532-440d-8bbc-428393dd7eb6@github.com> On Tue, 31 Jan 2023 19:18:07 GMT, Bill Huang wrote: > This task is created to update jtreg test to run on x86 only because pmem emulation is only supported on x86. For other architectures with external NVRAM, run test with java PmemTest. Maybe @adinn could comment on this as I thought this test was meant for both x64 and aarch64. ------------- PR: https://git.openjdk.org/jdk/pull/12352