From alanb at openjdk.java.net Fri Oct 1 06:50:24 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 1 Oct 2021 06:50:24 GMT Subject: RFR: 8274562: (fs) UserDefinedFileAttributeView doesn't correctly determine if supported when using OverlayFS In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 21:03:14 GMT, Brian Burkhalter wrote: > Add extended attributes to capabilities flag if `_SYS_XATTR_H` is defined. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5782 From alanb at openjdk.java.net Fri Oct 1 07:43:32 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 1 Oct 2021 07:43:32 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v4] In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 22:32:09 GMT, Brian Burkhalter wrote: >> This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8268435: Split up @Tests into multiple, smaller @Tests Thanks for the update, the test is much better now. @LanceAndersen Do you have any comments on this one? ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5645 From lancea at openjdk.java.net Fri Oct 1 11:09:33 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 1 Oct 2021 11:09:33 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v4] In-Reply-To: References: Message-ID: <5_X5nMOsLU81Inu5BP5JiuFcMI1nH1Z7wGvTgCQ6rqg=.c6900141-6f70-44f5-972b-696926769f84@github.com> On Wed, 29 Sep 2021 22:32:09 GMT, Brian Burkhalter wrote: >> This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8268435: Split up @Tests into multiple, smaller @Tests Hi Brian, Looks good overall. A couple minor suggestions for you to consider but I am good to go either way. test/jdk/java/nio/channels/Channels/ReadXBytes.java line 64: > 62: private static final int BIG_LENGTH = ArraysSupport.SOFT_MAX_ARRAY_LENGTH; > 63: private static final long HUGE_LENGTH = Integer.MAX_VALUE + 27L; > 64: Perhaps consider adding a comment for the above length constants test/jdk/java/nio/channels/Channels/ReadXBytes.java line 233: > 231: assertEquals(bytes.length, (long)length); > 232: } > 233: ); It has been suggested in past PR reviews (including a few of mine) that we use assertThrows(). vs the expectedException annotation element. Something you might want to consider using here ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5645 From github.com+1701815+mkarg at openjdk.java.net Fri Oct 1 15:06:36 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Fri, 1 Oct 2021 15:06:36 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v4] In-Reply-To: <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> References: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> Message-ID: On Wed, 29 Sep 2021 22:33:41 GMT, Brian Burkhalter wrote: >> Markus KARG has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment for checkTransferredContents >> >> Signed-off-by: Markus Karg > > test/jdk/java/nio/channels/Channels/TransferTo.java line 28: > >> 26: import static org.testng.Assert.assertEquals; >> 27: import static org.testng.Assert.assertThrows; >> 28: import static org.testng.Assert.assertTrue; > > Static imports in tests are usually grouped by convention after regular imports. I assume this is a OpenJDK convention? Because all IDEs I used so far sorted them *before* regular imports. I will fix that. > test/jdk/java/nio/channels/Channels/TransferTo.java line 105: > >> 103: checkTransferredContents(inputStreamProvider, outputStreamProvider, new byte[0]); >> 104: >> 105: // tests input stream with a lenght between 1k and 4k > > "lenght" should be "length" Good catch! I will fix that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Fri Oct 1 15:11:32 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Fri, 1 Oct 2021 15:11:32 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v4] In-Reply-To: <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> References: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> Message-ID: <5v_LSpUgg5nGalLhfC8e53sLkX0xlh39rE3FFsWnkYQ=.25b7ea6d-b5cb-485b-b7a6-a85f79b2be3a@github.com> On Wed, 29 Sep 2021 22:35:29 GMT, Brian Burkhalter wrote: > The comments are much improved but inconsistent. For example some of them have `@param` and other javadoc tags and some do not. There is also some variation in detail level. Is it essential for *this* PR that *all* comments must be consistent? I understood @AlanBateman in a way that it is enough to simply *have some* and honestly, I did not find such high quality comments in all the existing code you showed me. Regarding the detail level, it even makes sense to only go into details *where needed* IMHO to not repeat the obvious. > On a process level, it would be better to wait for feedback on changes before integrating. This is especially so as a sponsor has to be comfortable with the content. Ideally at least one approval should be associated with the most recent commit. Understood. I thought that it is irrelevant when I ask for integration, as I already covered all open issues and @shipilev already marked this PR as reviewed *as-is* (*without* any comments at all). ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From bpb at openjdk.java.net Fri Oct 1 15:34:35 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 1 Oct 2021 15:34:35 GMT Subject: Integrated: 8274562: (fs) UserDefinedFileAttributeView doesn't correctly determine if supported when using OverlayFS In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 21:03:14 GMT, Brian Burkhalter wrote: > Add extended attributes to capabilities flag if `_SYS_XATTR_H` is defined. This pull request has now been integrated. Changeset: 3d7671b6 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/3d7671b65e8491f3b1fcac8b96401401f783c9f4 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8274562: (fs) UserDefinedFileAttributeView doesn't correctly determine if supported when using OverlayFS Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5782 From github.com+1701815+mkarg at openjdk.java.net Fri Oct 1 15:45:06 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Fri, 1 Oct 2021 15:45:06 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v5] In-Reply-To: References: Message-ID: > Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. > > This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. > > *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Static imports in tests are usually grouped by convention after regular imports. Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5421/files - new: https://git.openjdk.java.net/jdk/pull/5421/files/0f056984..3301a86d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=03-04 Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5421/head:pull/5421 PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Fri Oct 1 15:45:08 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Fri, 1 Oct 2021 15:45:08 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v4] In-Reply-To: References: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> Message-ID: On Fri, 1 Oct 2021 15:02:58 GMT, Markus KARG wrote: >> test/jdk/java/nio/channels/Channels/TransferTo.java line 28: >> >>> 26: import static org.testng.Assert.assertEquals; >>> 27: import static org.testng.Assert.assertThrows; >>> 28: import static org.testng.Assert.assertTrue; >> >> Static imports in tests are usually grouped by convention after regular imports. > > I assume this is a OpenJDK convention? Because all IDEs I used so far sorted them *before* regular imports. I will fix that. Done by https://github.com/openjdk/jdk/pull/5421/commits/3301a86d4381d1d12a57cbbe57010f58cafef084. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Fri Oct 1 15:50:00 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Fri, 1 Oct 2021 15:50:00 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v6] In-Reply-To: References: Message-ID: > Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. > > This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. > > *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* Markus KARG has updated the pull request incrementally with one additional commit since the last revision: "lenght" should be "length" Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5421/files - new: https://git.openjdk.java.net/jdk/pull/5421/files/3301a86d..efa8ace1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5421/head:pull/5421 PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Fri Oct 1 15:50:03 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Fri, 1 Oct 2021 15:50:03 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v4] In-Reply-To: References: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> Message-ID: On Fri, 1 Oct 2021 15:03:16 GMT, Markus KARG wrote: >> test/jdk/java/nio/channels/Channels/TransferTo.java line 105: >> >>> 103: checkTransferredContents(inputStreamProvider, outputStreamProvider, new byte[0]); >>> 104: >>> 105: // tests input stream with a lenght between 1k and 4k >> >> "lenght" should be "length" > > Good catch! I will fix that. Done by https://github.com/openjdk/jdk/pull/5421/commits/efa8ace1db80ed51006948f201675d224fd14dea ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From bpb at openjdk.java.net Fri Oct 1 15:53:10 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 1 Oct 2021 15:53:10 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v5] In-Reply-To: References: Message-ID: > This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8268435: More comments; use assertThrows() instead of expectedExceptions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5645/files - new: https://git.openjdk.java.net/jdk/pull/5645/files/2b131c08..5d1eec3f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5645&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5645&range=03-04 Stats: 15 lines in 1 file changed: 4 ins; 5 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5645/head:pull/5645 PR: https://git.openjdk.java.net/jdk/pull/5645 From bpb at openjdk.java.net Fri Oct 1 16:01:07 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 1 Oct 2021 16:01:07 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v9] In-Reply-To: <8vwe-oQ5ilpMKuep4zSHycQisXMIFImfyE4hRVFvCS8=.c0fbf5b2-ccf3-46f4-bce1-6bb5fb3403e3@github.com> References: <8vwe-oQ5ilpMKuep4zSHycQisXMIFImfyE4hRVFvCS8=.c0fbf5b2-ccf3-46f4-bce1-6bb5fb3403e3@github.com> Message-ID: On Sat, 31 Jul 2021 00:59:19 GMT, Brian Burkhalter wrote: >> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`. >> >> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.) >> >> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension. >> >> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero. >> >> The behavior of the proposed method for some example cases is as: >> >> >> . -> >> .. -> >> .a.b -> b >> ...... -> >> .....a -> a >> ....a.b -> b >> ..foo -> foo >> test.rb -> rb >> a/b/d/test.rb -> rb >> .a/b/d/test.rb -> rb >> foo. -> >> test -> >> .profile -> >> .profile.sh -> sh >> ..foo -> foo >> .....foo -> foo >> .vimrc -> >> test. -> >> test.. -> >> test... -> >> foo.tar.gz -> gz >> foo.bar. -> >> image.jpg -> jpg >> music.mp3 -> mp3 >> video.mp4 -> mp4 >> document.txt -> txt >> foo.tar.gz -> gz >> foo.bar. -> > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - 8057113: Optimistically update @since tag to 18 > - Merge > - 8057113: Change first sentence; change param name > - 8057113: Change Path.getExtension() to accept a default return value in case the extension is indeterminate > - 8057113: Tweak spec again, and @implSpec code > - 8057113: Add @since tag > - 8057113: Tweak first sentence of spec > - 8057113: Handle getFileName() == null; revise spec > - 8057113: Changes pursuant to PR conversation > - 8057113: (fs) Path should have a method to obtain the filename extension Still in progress ... ------------- PR: https://git.openjdk.java.net/jdk/pull/2319 From lancea at openjdk.java.net Fri Oct 1 16:01:31 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 1 Oct 2021 16:01:31 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v5] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 15:53:10 GMT, Brian Burkhalter wrote: >> This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8268435: More comments; use assertThrows() instead of expectedExceptions Thank you Brian for the last updates. Looks good. :-) ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5645 From github.com+1701815+mkarg at openjdk.java.net Fri Oct 1 17:09:06 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Fri, 1 Oct 2021 17:09:06 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v7] In-Reply-To: References: Message-ID: > Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. > > This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. > > *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Removed Javadoc Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5421/files - new: https://git.openjdk.java.net/jdk/pull/5421/files/efa8ace1..54b7438b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=05-06 Stats: 16 lines in 1 file changed: 0 ins; 12 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5421/head:pull/5421 PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Fri Oct 1 17:09:09 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Fri, 1 Oct 2021 17:09:09 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v4] In-Reply-To: <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> References: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> Message-ID: On Wed, 29 Sep 2021 22:35:29 GMT, Brian Burkhalter wrote: >> Markus KARG has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment for checkTransferredContents >> >> Signed-off-by: Markus Karg > > The comments are much improved but inconsistent. For example some of them have `@param` and other javadoc tags and some do not. There is also some variation in detail level. > > On a process level, it would be better to wait for feedback on changes before integrating. This is especially so as a sponsor has to be comfortable with the content. Ideally at least one approval should be associated with the most recent commit. @bplb > The comments are much improved but inconsistent. For example some of them have `@param` and other javadoc tags and some do not. There is also some variation in detail level. Maybe Javadoc for test support code is excessive, and is the major source of inconsistency here. I dropped them to be more in line with the rest of comments, see https://github.com/openjdk/jdk/pull/5421/commits/54b7438b72fcfc20889dbb4140ff7aa2d5279642. But beyond that, I don't understand what do you mean about the different level of detail, would you mind suggesting changes where you see fit? ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From bpb at openjdk.java.net Fri Oct 1 20:19:38 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 1 Oct 2021 20:19:38 GMT Subject: Integrated: 8268435: (ch) ChannelInputStream could override readAllBytes In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 01:52:31 GMT, Brian Burkhalter wrote: > This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. This pull request has now been integrated. Changeset: 0786d8b7 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/0786d8b7b367e3aa3ffa54a3e339572938378dca Stats: 415 lines in 3 files changed: 404 ins; 3 del; 8 mod 8268435: (ch) ChannelInputStream could override readAllBytes Reviewed-by: alanb, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5645 From github.com+30833588+dmor01 at openjdk.java.net Fri Oct 1 23:50:40 2021 From: github.com+30833588+dmor01 at openjdk.java.net (Dmor01) Date: Fri, 1 Oct 2021 23:50:40 GMT Subject: RFR: 8274562: (fs) UserDefinedFileAttributeView doesn't correctly determine if supported when using OverlayFS In-Reply-To: References: Message-ID: <7stkCKP83Q95JqMmo1Ji7seRHdntaOk_wctHjaFUIM4=.ae6a39d7-45f0-4527-86c2-397673293375@github.com> On Thu, 30 Sep 2021 21:03:14 GMT, Brian Burkhalter wrote: > Add extended attributes to capabilities flag if `_SYS_XATTR_H` is defined. @bplb would it be possible to get the fix for 8274562 backported to JDK17? ------------- PR: https://git.openjdk.java.net/jdk/pull/5782 From brian.burkhalter at oracle.com Sat Oct 2 01:34:16 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Sat, 2 Oct 2021 01:34:16 +0000 Subject: RFR: 8274562: (fs) UserDefinedFileAttributeView doesn't correctly determine if supported when using OverlayFS In-Reply-To: <7stkCKP83Q95JqMmo1Ji7seRHdntaOk_wctHjaFUIM4=.ae6a39d7-45f0-4527-86c2-397673293375@github.com> References: <7stkCKP83Q95JqMmo1Ji7seRHdntaOk_wctHjaFUIM4=.ae6a39d7-45f0-4527-86c2-397673293375@github.com> Message-ID: On Oct 1, 2021, at 4:50 PM, Dmor01 > wrote: On Thu, 30 Sep 2021 21:03:14 GMT, Brian Burkhalter > wrote: Add extended attributes to capabilities flag if `_SYS_XATTR_H` is defined. @bplb would it be possible to get the fix for 8274562 backported to JDK17? I hope so. I?ll put the topic in my list for next week. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Tue Oct 5 13:46:16 2021 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 5 Oct 2021 08:46:16 -0500 Subject: Circular loading of installed providers detected In-Reply-To: <0C7F8DDC-4EF8-450E-BBB9-BAD73F3DF984@gmail.com> References: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> <0C7F8DDC-4EF8-450E-BBB9-BAD73F3DF984@gmail.com> Message-ID: > On Sep 30, 2021, at 1:02 PM, Michael Hall wrote: > > > >> On Sep 30, 2021, at 4:25 AM, Michael Hall > wrote: >>> >> >> Possibly the code could at some point check the java.nio.file.spi.DefaultFileSystemProvider property to be sure it wasn?t trying to reload the current default anyhow. > > It still seems a bit of a awkward workaround but for a DefaultFileSystemProvider that saves its priorProvider static and includes a no-args that does nothing it works. I?m not sure if this would be necessary for any code that uses multiple providers. Or just code that replaces the default and then tries for another provider. > > For this > > error: No file system provider is available to handle this file: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app/halfpipe.j > I found this indicating I needed an additional module? > Sort of oddly. I was going to come up with a JDK16 version of the application to get around some JDK17 encapsulation errors for some 3rd party code. For JShell these messages come back? /Users/mjh/HalfPipe/HalfPipe_jpkg/HalfPipe16.app/Contents/app/httpcore5-5.0.2.jar error: No file system provider is available to handle this file: My jpackage invocation still has a ?add-modules that includes jdk.zipfs If I do a ?list-modules against the embedded runtime it doesn?t show up? HalfPipe16.app/Contents/runtime/Contents/Home/bin/java --list-modules | grep zipfs The OS/X installed jdk16 includes it? /usr/libexec/java_home -v 16 --exec java --list-modules | grep zipfs jdk.zipfs at 16 I did remove the parameter for my DefaultFileSystemProvider as that did not work at jdk16. If it is being found by discovery it should be the current version with the circular workaround. I am not sure why the jdk16 jpackage/jlink runtime misses the zipfs module? But so far other than looking messy starting JShell it doesn?t seem to cause any problems. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Tue Oct 5 13:58:36 2021 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 5 Oct 2021 08:58:36 -0500 Subject: Circular loading of installed providers detected In-Reply-To: References: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> <0C7F8DDC-4EF8-450E-BBB9-BAD73F3DF984@gmail.com> Message-ID: > On Oct 5, 2021, at 8:46 AM, Michael Hall wrote: > > > >> On Sep 30, 2021, at 1:02 PM, Michael Hall > wrote: >> >> >> >>> On Sep 30, 2021, at 4:25 AM, Michael Hall > wrote: >>>> >>> >>> Possibly the code could at some point check the java.nio.file.spi.DefaultFileSystemProvider property to be sure it wasn?t trying to reload the current default anyhow. >> >> It still seems a bit of a awkward workaround but for a DefaultFileSystemProvider that saves its priorProvider static and includes a no-args that does nothing it works. I?m not sure if this would be necessary for any code that uses multiple providers. Or just code that replaces the default and then tries for another provider. >> >> For this >> >> error: No file system provider is available to handle this file: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app/halfpipe.j >> I found this indicating I needed an additional module? >> > > Sort of oddly. For completeness if anyone cares to try and recreate, the jpackage ?add-modules --add-modules us.hall.eio,org.openjdk.nashorn,java.compiler,java.desktop,java.logging,java.management,jdk.management.agent,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell,jdk.crypto.ec,jdk.jdeps,jdk.jcmd,jdk.zipfs \ The ?list-modules output? HalfPipe16.app/Contents/runtime/Contents/Home/bin/java --list-modules java.base at 16 java.compiler at 16 java.datatransfer at 16 java.desktop at 16 java.instrument at 16 java.logging at 16 java.management at 16 java.management.rmi at 16 java.naming at 16 java.net.http at 16 java.prefs at 16 java.rmi at 16 java.scripting at 16 java.se at 16 java.security.jgss at 16 java.security.sasl at 16 java.sql at 16 java.sql.rowset at 16 java.transaction.xa at 16 java.xml at 16 java.xml.crypto at 16 jdk.attach at 16 jdk.compiler at 16 jdk.crypto.ec at 16 jdk.dynalink at 16 jdk.internal.ed at 16 jdk.internal.jvmstat at 16 jdk.internal.le at 16 jdk.internal.opt at 16 jdk.jdi at 16 jdk.jdwp.agent at 16 jdk.jshell at 16 jdk.unsupported at 16 org.objectweb.asm at 7.3.1 open org.objectweb.asm.commons at 7.3.1 open org.objectweb.asm.tree at 7.3.1 open org.objectweb.asm.tree.analysis at 7.3.1 open org.objectweb.asm.util at 7.3.1 open org.openjdk.nashorn us.hall.trz.osx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Oct 5 13:58:53 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Oct 2021 14:58:53 +0100 Subject: Circular loading of installed providers detected In-Reply-To: References: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> <0C7F8DDC-4EF8-450E-BBB9-BAD73F3DF984@gmail.com> Message-ID: On 05/10/2021 14:46, Michael Hall wrote: > > > Sort of oddly. > I was going to come up with a JDK16 version of the application to get > around some JDK17 encapsulation errors for some 3rd party code. > For JShell these messages come back? > > /Users/mjh/HalfPipe/HalfPipe_jpkg/HalfPipe16.app/Contents/app/httpcore5-5.0.2.jar > error: No file system provider is available to handle this file: > > My jpackage invocation still has a ?add-modules that includes jdk.zipfs > If I do a ?list-modules against the embedded runtime it doesn?t show up? > > HalfPipe16.app/Contents/runtime/Contents/Home/bin/java --list-modules > | grep zipfs > > The OS/X installed jdk16 includes it? > /usr/libexec/java_home -v 16 --exec java --list-modules | grep zipfs > jdk.zipfs at 16 > > I did remove the parameter for my DefaultFileSystemProvider as that > did not work at jdk16. If it is being found by discovery it should be > the ?current version with the circular workaround. > > I am not sure why the jdk16 jpackage/jlink runtime misses the zipfs > module? But so far other than looking messy starting JShell it doesn?t > seem to cause any problems. > jdk.zipfs is a service provider module so no module requires it. So yes, you'll ned to keep it on the list of modules that you specify to the jlink --add-modules option. -Alan From mik3hall at gmail.com Tue Oct 5 14:01:03 2021 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 5 Oct 2021 09:01:03 -0500 Subject: Circular loading of installed providers detected In-Reply-To: References: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> <0C7F8DDC-4EF8-450E-BBB9-BAD73F3DF984@gmail.com> Message-ID: <6D8E949B-D935-4186-84A4-296F68F7020C@gmail.com> > On Oct 5, 2021, at 8:58 AM, Alan Bateman wrote: > >> > jdk.zipfs is a service provider module so no module requires it. So yes, you'll ned to keep it on the list of modules that you specify to the jlink --add-modules option. > > -Alan Yes, I assumed this. What seems incorrect is that although I add it at jdk16 it still didn?t get included. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at openjdk.java.net Tue Oct 5 14:53:20 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Tue, 5 Oct 2021 14:53:20 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() Message-ID: ?Bytes() ------------- Commit messages: - 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() Changes: https://git.openjdk.java.net/jdk/pull/5824/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5824&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274780 Stats: 29 lines in 2 files changed: 26 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5824.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5824/head:pull/5824 PR: https://git.openjdk.java.net/jdk/pull/5824 From fweimer at openjdk.java.net Tue Oct 5 14:53:20 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Tue, 5 Oct 2021 14:53:20 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() In-Reply-To: References: Message-ID: <9mfrw_Q6Za4GiiAdgFcUAK6JoKUACyIXkGC2TycONro=.565e3e8b-466b-4e21-9451-b802ebe2aac7@github.com> On Tue, 5 Oct 2021 14:46:26 GMT, Florian Weimer wrote: > ?Bytes() I had to increase the test timeout. Even the original test required about 8 minutes to run on my test machines, which has pretty good single-thread performance. ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From fweimer at openjdk.java.net Tue Oct 5 14:56:11 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Tue, 5 Oct 2021 14:56:11 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v5] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 15:53:10 GMT, Brian Burkhalter wrote: >> This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8268435: More comments; use assertThrows() instead of expectedExceptions This introduced [JDK-8274780](https://bugs.openjdk.java.net/browse/JDK-8274780). Fixed proposed via #5824. ------------- PR: https://git.openjdk.java.net/jdk/pull/5645 From bpb at openjdk.java.net Tue Oct 5 17:05:12 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 5 Oct 2021 17:05:12 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() In-Reply-To: References: Message-ID: <6AcrQwod8vD9if9-AeTtheyfvFgbGF_mpt30Rq7KsTU=.f9527f6e-254f-474a-9e43-954fc4b747dc@github.com> On Tue, 5 Oct 2021 14:46:26 GMT, Florian Weimer wrote: > 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() test/jdk/java/nio/channels/Channels/ReadXBytes.java line 160: > 158: ReadableByteChannel ch = Channels.newChannel( > 159: new FilterInputStream(fis2) {}); > 160: InputStream cis = Channels.newInputStream(ch)) { With four resources in the `try`, this `try-with-resources` is a little hard to read. Perhaps use two nested `t-w-r`s instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From alanb at openjdk.java.net Tue Oct 5 17:13:13 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 5 Oct 2021 17:13:13 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 14:46:26 GMT, Florian Weimer wrote: > 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() test/jdk/java/nio/channels/Channels/ReadXBytes.java line 32: > 30: * @build jdk.test.lib.RandomFactory > 31: * @modules java.base/jdk.internal.util > 32: * @run testng/othervm/timeout=3600 -Xmx8G ReadXBytes Are you running the tests with the make target or jtreg without -timeoutFactor? test/jdk/java/nio/channels/Channels/ReadXBytes.java line 163: > 161: f.test(length, cis, fis); > 162: } finally { > 163: Files.delete(file); I'd like to see this cleaned up a bit. The line break at L154 make it hard to read. Having 4 resources in the same try-with-resources is also hard to read. The comment "relationship is obscured" will confuse further maintainers. ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From fweimer at openjdk.java.net Tue Oct 5 17:19:11 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Tue, 5 Oct 2021 17:19:11 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() In-Reply-To: References: Message-ID: <_PBbRiVoOf80xnJx11v01XHlLmIWJPTb8IuVJBuJSF4=.7810bc84-95e1-45b7-b528-b030ad6914f8@github.com> On Tue, 5 Oct 2021 15:02:13 GMT, Alan Bateman wrote: >> 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() > > test/jdk/java/nio/channels/Channels/ReadXBytes.java line 32: > >> 30: * @build jdk.test.lib.RandomFactory >> 31: * @modules java.base/jdk.internal.util >> 32: * @run testng/othervm/timeout=3600 -Xmx8G ReadXBytes > > Are you running the tests with the make target or jtreg without -timeoutFactor? I'm invoking jtreg directly, following [Running tests using jtreg](http://openjdk.java.net/jtreg/runtests.html). That page doesn't mention `-timeoutFactor`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From mik3hall at gmail.com Tue Oct 5 17:30:44 2021 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 5 Oct 2021 12:30:44 -0500 Subject: Circular loading of installed providers detected In-Reply-To: <6D8E949B-D935-4186-84A4-296F68F7020C@gmail.com> References: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> <0C7F8DDC-4EF8-450E-BBB9-BAD73F3DF984@gmail.com> <6D8E949B-D935-4186-84A4-296F68F7020C@gmail.com> Message-ID: > On Oct 5, 2021, at 9:01 AM, Michael Hall wrote: > > > >> On Oct 5, 2021, at 8:58 AM, Alan Bateman > wrote: >> >>> >> jdk.zipfs is a service provider module so no module requires it. So yes, you'll ned to keep it on the list of modules that you specify to the jlink --add-modules option. >> >> -Alan > > Yes, I assumed this. What seems incorrect is that although I add it at jdk16 it still didn?t get included. > It might of been service provider failing due to my custom default provider somehow. I couldn?t recreate with just jlink. Falling back to 16 isn?t that easy at this point. OS/X entitlements worked differently, there was a java.library.path issue at 16. I removed the parameter for DefaultFileSystemProvider but I think at some point it still was being found in discovery and it won?t work at 16. I removed the jar as well. I guess this seems the most likely cause of the missing zipfs module but I didn?t isolate it to that for sure. The application itself still doesn?t launch double clicked, indicating incomplete, but if I double click the MacOS executable it runs. And the 3rd party code works. (Although still showing the error I thought it was failing on) I?ll probably have to fix the double click failure somehow before providing it for anyone to try. So some confusion still between versions and mixing in my provider and maybe building the app but it does seem specific to what mine is doing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at openjdk.java.net Tue Oct 5 17:39:08 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Tue, 5 Oct 2021 17:39:08 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() In-Reply-To: References: Message-ID: <0eb2Q5dzdA5KADBFhR-MYWcdIPcAnIaG0D4zEvM8Qfw=.88918fd7-9634-4df1-85bb-c0a1f8292472@github.com> On Tue, 5 Oct 2021 15:06:39 GMT, Alan Bateman wrote: >> 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() > > test/jdk/java/nio/channels/Channels/ReadXBytes.java line 163: > >> 161: f.test(length, cis, fis); >> 162: } finally { >> 163: Files.delete(file); > > I'd like to see this cleaned up a bit. The line break at L154 make it hard to read. Having 4 resources in the same try-with-resources is also hard to read. The comment "relationship is obscured" will confuse further maintainers. How important is exception correctness in the test code? Is it acceptable to leak resources on VM errors? ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From alanb at openjdk.java.net Tue Oct 5 17:47:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 5 Oct 2021 17:47:09 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() In-Reply-To: <_PBbRiVoOf80xnJx11v01XHlLmIWJPTb8IuVJBuJSF4=.7810bc84-95e1-45b7-b528-b030ad6914f8@github.com> References: <_PBbRiVoOf80xnJx11v01XHlLmIWJPTb8IuVJBuJSF4=.7810bc84-95e1-45b7-b528-b030ad6914f8@github.com> Message-ID: <_uiwIvgXfo-McmRXFOqB0pZhCTQISyGV4wQMuXvmZKQ=.80974100-7cd1-4d4a-a348-b27590020f07@github.com> On Tue, 5 Oct 2021 17:16:56 GMT, Florian Weimer wrote: > I'm invoking jtreg directly, following [Running tests using jtreg](http://openjdk.java.net/jtreg/runtests.html). That page doesn't mention `-timeoutFactor`. Okay, I think RunTests.gmk sets it to 4 but it can be overridden. > How important is exception correctness in the test code? Is it acceptable to leak resources on VM errors? The tests usually run in agentvm mode so if failing tests leak then it may have knock impact to tests that run later in the same VM. So if we can clean up then we should. Sometimes we have tests that can't reliably cleanup, they can run in othervm mode that is runs just the one test. ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From fweimer at openjdk.java.net Tue Oct 5 17:52:15 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Tue, 5 Oct 2021 17:52:15 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() In-Reply-To: <_uiwIvgXfo-McmRXFOqB0pZhCTQISyGV4wQMuXvmZKQ=.80974100-7cd1-4d4a-a348-b27590020f07@github.com> References: <_PBbRiVoOf80xnJx11v01XHlLmIWJPTb8IuVJBuJSF4=.7810bc84-95e1-45b7-b528-b030ad6914f8@github.com> <_uiwIvgXfo-McmRXFOqB0pZhCTQISyGV4wQMuXvmZKQ=.80974100-7cd1-4d4a-a348-b27590020f07@github.com> Message-ID: On Tue, 5 Oct 2021 17:43:42 GMT, Alan Bateman wrote: >> How important is exception correctness in the test code? Is it acceptable to leak resources on VM errors? > >> How important is exception correctness in the test code? Is it acceptable to leak resources on VM errors? > > The tests usually run in agentvm mode so if failing tests leak then it may have knock impact to tests that run later in the same VM. So if we can clean up then we should. Sometimes we have tests that can't reliably cleanup, they can run in othervm mode that is runs just the one test. I meant whether it's acceptable to use a construct like `try (var ch = Channels.newInputStream(new FileInputStream(f)))`. The input stream could leak there, but only in case of VM errors. ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From fweimer at openjdk.java.net Tue Oct 5 17:56:08 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Tue, 5 Oct 2021 17:56:08 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() In-Reply-To: <_uiwIvgXfo-McmRXFOqB0pZhCTQISyGV4wQMuXvmZKQ=.80974100-7cd1-4d4a-a348-b27590020f07@github.com> References: <_PBbRiVoOf80xnJx11v01XHlLmIWJPTb8IuVJBuJSF4=.7810bc84-95e1-45b7-b528-b030ad6914f8@github.com> <_uiwIvgXfo-McmRXFOqB0pZhCTQISyGV4wQMuXvmZKQ=.80974100-7cd1-4d4a-a348-b27590020f07@github.com> Message-ID: <2avS6WUzOyPa-CNA5nICeSlTbjcbgdVi-xv9FGdceUM=.85ad0e16-7153-4442-8281-95f4a8cab6cb@github.com> On Tue, 5 Oct 2021 17:44:20 GMT, Alan Bateman wrote: >> I'm invoking jtreg directly, following [Running tests using jtreg](http://openjdk.java.net/jtreg/runtests.html). That page doesn't mention `-timeoutFactor`. > >> I'm invoking jtreg directly, following [Running tests using jtreg](http://openjdk.java.net/jtreg/runtests.html). That page doesn't mention `-timeoutFactor`. > > Okay, I think RunTests.gmk sets it to 4 but it can be overridden. Should I lower the timeout to 900 then? With a factor of 4, that should be enough to run the test even on fairly slow machines. ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From fweimer at openjdk.java.net Tue Oct 5 20:38:29 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Tue, 5 Oct 2021 20:38:29 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() [v2] In-Reply-To: References: Message-ID: > 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() Florian Weimer has updated the pull request incrementally with two additional commits since the last revision: - Simplify dataTest() implementation - Reduce test timeout somewhat (based on default timeout factor) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5824/files - new: https://git.openjdk.java.net/jdk/pull/5824/files/ef27e26f..46e556d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5824&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5824&range=00-01 Stats: 31 lines in 1 file changed: 3 ins; 11 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5824.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5824/head:pull/5824 PR: https://git.openjdk.java.net/jdk/pull/5824 From bpb at openjdk.java.net Wed Oct 6 00:08:24 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 6 Oct 2021 00:08:24 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 Message-ID: On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. ------------- Commit messages: - 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 Changes: https://git.openjdk.java.net/jdk/pull/5831/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274548 Stats: 161 lines in 2 files changed: 160 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5831/head:pull/5831 PR: https://git.openjdk.java.net/jdk/pull/5831 From bpb at openjdk.java.net Wed Oct 6 00:08:25 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 6 Oct 2021 00:08:25 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 00:00:00 GMT, Brian Burkhalter wrote: > On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. The `writev()` function on Linux is specified to fail if: EINVAL The sum of the iov_len values in the iov array would overflow an ssize_t. and similarly on macOS: [EINVAL] The sum of the iov_len values in the iov array overflows a 32-bit integer. On Linux, `writev()` was observed _not_ to fail for this case but to return `0x7ffff000`, the maximum number of bytes that `sendfile()` can transfer. This of course might not be the case on all Linux variants. The error could be handled by a code change in `IOUtil` but then it would affect all platforms. Also, on macOS the problem has only been observed on one version of the operating system so the added native code would not be always be called even though compiled. It would however probably be harmless to conditionally compile the code for Linux as well as macOS. Testing has verified the fix on macOS 11.6 and earlier macOS versions with no effect (of course) on Linux. ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From alanb at openjdk.java.net Wed Oct 6 06:55:06 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 6 Oct 2021 06:55:06 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 00:00:00 GMT, Brian Burkhalter wrote: > On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. We really need someone from Apple here to tell us if this is a man page issue or a bug in macOS 11.6. If I read it correctly, the issue doesn't occur with 10.5.x and the best of macOS 12, is that correct? If we do need to put a workaround in for this then I think it will need an overhaul of IOUtil first. I'd prefer not have the iovec array be modified in two places. ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From github.com+10835776+stsypanov at openjdk.java.net Wed Oct 6 07:23:21 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 6 Oct 2021 07:23:21 GMT Subject: RFR: 8274811: Remove superfluous use of boxing in java.base In-Reply-To: References: Message-ID: On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov wrote: > Usages of primitive types should be preferred and makes code easier to read. > Similar cleanups: > 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop > 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset src/java.base/share/classes/java/util/ResourceBundle.java line 3732: > 3730: } > 3731: > 3732: private static final boolean TRACE_ON = Boolean.parseBoolean( I think for `Boolean` it doesn't make significant difference, as both `Boolean.TRUE` and `Boolean.FALSE` are cached and initialized immediately along with the class itself: public static Boolean valueOf(String s) { return parseBoolean(s) ? TRUE : FALSE; } ------------- PR: https://git.openjdk.java.net/jdk/pull/5481 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 07:23:20 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 07:23:20 GMT Subject: RFR: 8274811: Remove superfluous use of boxing in java.base Message-ID: Usages of primitive types should be preferred and makes code easier to read. Similar cleanups: 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset ------------- Commit messages: - [PATCH] Remove superfluous use of boxing in java.base - [PATCH] Remove superfluous use of boxing in java.* modules - [PATCH] Remove superfluous use of boxing in java.* modules Changes: https://git.openjdk.java.net/jdk/pull/5481/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5481&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274811 Stats: 11 lines in 4 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5481.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5481/head:pull/5481 PR: https://git.openjdk.java.net/jdk/pull/5481 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 07:23:22 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 07:23:22 GMT Subject: RFR: 8274811: Remove superfluous use of boxing in java.base In-Reply-To: References: Message-ID: On Sat, 11 Sep 2021 17:22:01 GMT, ?????? ??????? wrote: >> Usages of primitive types should be preferred and makes code easier to read. >> Similar cleanups: >> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop >> 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset > > src/java.base/share/classes/java/util/ResourceBundle.java line 3732: > >> 3730: } >> 3731: >> 3732: private static final boolean TRACE_ON = Boolean.parseBoolean( > > I think for `Boolean` it doesn't make significant difference, as both `Boolean.TRUE` and `Boolean.FALSE` are cached and initialized immediately along with the class itself: > > public static Boolean valueOf(String s) { > return parseBoolean(s) ? TRUE : FALSE; > } Yes, there is no allocation for booleans. But still 2 redundant method calls in interpreter mode (valueOf+booleanValue) ------------- PR: https://git.openjdk.java.net/jdk/pull/5481 From alanb at openjdk.java.net Wed Oct 6 08:40:21 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 6 Oct 2021 08:40:21 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() [v2] In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 20:38:29 GMT, Florian Weimer wrote: >> 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() > > Florian Weimer has updated the pull request incrementally with two additional commits since the last revision: > > - Simplify dataTest() implementation > - Reduce test timeout somewhat (based on default timeout factor) Marked as reviewed by alanb (Reviewer). test/jdk/java/nio/channels/Channels/ReadXBytes.java line 139: > 137: Path file = c.create(length); > 138: try { > 139: for (boolean hideSeek : List.of(false, true)) { It might be a bit clearer if you renamed this to "seekable" ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From fweimer at openjdk.java.net Wed Oct 6 10:54:34 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Wed, 6 Oct 2021 10:54:34 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() [v3] In-Reply-To: References: Message-ID: > 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() Florian Weimer has updated the pull request incrementally with one additional commit since the last revision: Replace hideSeek with seekable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5824/files - new: https://git.openjdk.java.net/jdk/pull/5824/files/46e556d0..43ec5689 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5824&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5824&range=01-02 Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5824.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5824/head:pull/5824 PR: https://git.openjdk.java.net/jdk/pull/5824 From alanb at openjdk.java.net Wed Oct 6 12:24:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 6 Oct 2021 12:24:08 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 10:54:34 GMT, Florian Weimer wrote: >> 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() > > Florian Weimer has updated the pull request incrementally with one additional commit since the last revision: > > Replace hideSeek with seekable Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From bpb at openjdk.java.net Wed Oct 6 19:29:29 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 6 Oct 2021 19:29:29 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v2] In-Reply-To: References: Message-ID: > On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274548: Move logic from C to Java layer ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5831/files - new: https://git.openjdk.java.net/jdk/pull/5831/files/27b5c920..6a9116b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=00-01 Stats: 72 lines in 3 files changed: 21 ins; 41 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5831/head:pull/5831 PR: https://git.openjdk.java.net/jdk/pull/5831 From bpb at openjdk.java.net Wed Oct 6 19:29:29 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 6 Oct 2021 19:29:29 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 00:00:00 GMT, Brian Burkhalter wrote: > On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. V1 moves the logic up to the Java level and removes all native code changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From brian.burkhalter at oracle.com Wed Oct 6 19:47:53 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 6 Oct 2021 19:47:53 +0000 Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 In-Reply-To: References: Message-ID: On Oct 5, 2021, at 11:55 PM, Alan Bateman > wrote: If I read it correctly, the issue doesn't occur with 10.5.x and the best of macOS 12, is that correct? That is correct: change in behavior was seen on 11.6 only; 10.5.x and 12-beta are identical and do not manifest it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.java.net Wed Oct 6 20:51:05 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 6 Oct 2021 20:51:05 GMT Subject: RFR: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 10:54:34 GMT, Florian Weimer wrote: >> 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() > > Florian Weimer has updated the pull request incrementally with one additional commit since the last revision: > > Replace hideSeek with seekable Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From bpb at openjdk.java.net Wed Oct 6 21:07:35 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 6 Oct 2021 21:07:35 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v3] In-Reply-To: References: Message-ID: > On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274548: Remove setting position which is not needed due to using absolute put ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5831/files - new: https://git.openjdk.java.net/jdk/pull/5831/files/6a9116b6..1d41dfbb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5831/head:pull/5831 PR: https://git.openjdk.java.net/jdk/pull/5831 From alanb at openjdk.java.net Thu Oct 7 07:03:13 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 7 Oct 2021 07:03:13 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 21:07:35 GMT, Brian Burkhalter wrote: >> On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274548: Remove setting position which is not needed due to using absolute put The latest version impacts all platforms. I think the first step here is to make contact with Apple and try to detect if this is an intended change in macOS 11.6 or not. The observation that they reverted it again in macOS 12 beta suggests it was unintentional but I think we need to find out more. ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From fweimer at openjdk.java.net Thu Oct 7 07:05:12 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Thu, 7 Oct 2021 07:05:12 GMT Subject: Integrated: 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 14:46:26 GMT, Florian Weimer wrote: > 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() This pull request has now been integrated. Changeset: 5762ec25 Author: Florian Weimer Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/5762ec25877ab9207a2fb05888f952690737e318 Stats: 25 lines in 2 files changed: 18 ins; 0 del; 7 mod 8274780: ChannelInputStream.readNBytes(int) incorrectly calls readAllBytes() Reviewed-by: alanb, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5824 From bpb at openjdk.java.net Thu Oct 7 16:27:12 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 7 Oct 2021 16:27:12 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 21:07:35 GMT, Brian Burkhalter wrote: >> On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274548: Remove setting position which is not needed due to using absolute put Not affecting all platforms is why it was in the C code in the first place. Apple indicates it was an intentional change in macOS 11.x where x >= 0. I don't know yet about 12. ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From bpb at openjdk.java.net Thu Oct 7 17:18:07 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 7 Oct 2021 17:18:07 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 21:07:35 GMT, Brian Burkhalter wrote: >> On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274548: Remove setting position which is not needed due to using absolute put My original evaluation on macOS 12-beta was incorrect: I re-tested and the problem occurs there as well. Therefore we are seeing it on `macOS x.y.z` where `x >= 11`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From bpb at openjdk.java.net Thu Oct 7 18:33:33 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 7 Oct 2021 18:33:33 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v4] In-Reply-To: References: Message-ID: <0iB1AW3KhcLJZLLbFEmMvpJK1_oEXhW9QxDGQgygDcw=.ee7add05-711d-44da-b57e-93d02116ef89@github.com> > On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274548: Native macOS-only code change with no modification of iovec array ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5831/files - new: https://git.openjdk.java.net/jdk/pull/5831/files/1d41dfbb..6da2c82e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=02-03 Stats: 44 lines in 2 files changed: 22 ins; 16 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5831/head:pull/5831 PR: https://git.openjdk.java.net/jdk/pull/5831 From bpb at openjdk.java.net Thu Oct 7 21:12:17 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 7 Oct 2021 21:12:17 GMT Subject: RFR: 8233749: Files.exists javadoc doesn't mention eating IOException Message-ID: Add `@see FileSystemProvider#checkAccess` link per the suggestion in the issue. ------------- Commit messages: - 8233749: Files.exists javadoc doesn't mention eating IOException Changes: https://git.openjdk.java.net/jdk/pull/5856/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5856&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233749 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5856/head:pull/5856 PR: https://git.openjdk.java.net/jdk/pull/5856 From bpb at openjdk.java.net Thu Oct 7 21:12:17 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 7 Oct 2021 21:12:17 GMT Subject: RFR: 8233749: Files.exists javadoc doesn't mention eating IOException In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:05:24 GMT, Brian Burkhalter wrote: > Add `@see FileSystemProvider#checkAccess` link per the suggestion in the issue. A CSR is not required for this small change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5856 From lancea at openjdk.java.net Thu Oct 7 21:23:06 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 7 Oct 2021 21:23:06 GMT Subject: RFR: 8233749: Files.exists javadoc doesn't mention eating IOException In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:05:24 GMT, Brian Burkhalter wrote: > Add `@see FileSystemProvider#checkAccess` link per the suggestion in the issue. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5856 From alanb at openjdk.java.net Fri Oct 8 05:52:05 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 8 Oct 2021 05:52:05 GMT Subject: RFR: 8233749: Files.exists javadoc doesn't mention eating IOException In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:05:24 GMT, Brian Burkhalter wrote: > Add `@see FileSystemProvider#checkAccess` link per the suggestion in the issue. You may want to change the JBS description to make it clear that this is just adding a link rather than changing the description. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5856 From alanb at openjdk.java.net Fri Oct 8 12:07:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 8 Oct 2021 12:07:08 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v4] In-Reply-To: <0iB1AW3KhcLJZLLbFEmMvpJK1_oEXhW9QxDGQgygDcw=.ee7add05-711d-44da-b57e-93d02116ef89@github.com> References: <0iB1AW3KhcLJZLLbFEmMvpJK1_oEXhW9QxDGQgygDcw=.ee7add05-711d-44da-b57e-93d02116ef89@github.com> Message-ID: On Thu, 7 Oct 2021 18:33:33 GMT, Brian Burkhalter wrote: >> On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274548: Native macOS-only code change with no modification of iovec array One approach is try to add a writevMax method along side of iovMax that returns the maximum value of the sum of the iov_len. If this is merged with your v2 then it might not be too bad. ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From github.com+1701815+mkarg at openjdk.java.net Fri Oct 8 16:34:12 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Fri, 8 Oct 2021 16:34:12 GMT Subject: RFR: 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo() [v10] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 16:05:09 GMT, Markus KARG wrote: >> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and deliberately concentrates **only** on `FileChannel`s. Other types of channels will be discussed in future PRs. >> >> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. >> >> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997). > > Markus KARG has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 11 new commits since the last revision: > > - 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo(WritableByteChannel) > > As suggested in 8265891 this change implements a performance optimization > for ChannelInputStream.transferTo(): It uses > FileChannel.transferTo(WritableByteChannel) in case the source channel > actually is a FileChannel and the target channel is a > WritableByteChannel, as in that case, > the actual work of transferring bytes can potentially get offloaded to the > operating system / file system. > > Signed-off-by: Markus Karg > - Added comma after year in copyright > > Signed-off-by: Markus Karg > - Copyright (C) 2021 instead of 2014, 2021 > > Signed-off-by: Markus Karg > - Replaced 'point' by 'position' in comments > > Signed-off-by: Markus Karg > - Moved TransferTo.java from test/jdk/sun/nio/ch/ChannelInputStream/ to test/jdk/java/nio/channels/Channels/ > > Signed-off-by: Markus Karg > - Redeced line lenght; maximum length now is 115 characters > > Signed-off-by: Markus Karg > - Removed static modifiers on interfaces > > Signed-off-by: Markus Karg > - Removed unused imports > > Signed-off-by: Markus Karg > - Renamed ifOutIsNullThenNpeIsThrows to testNullPointerException > > Signed-off-by: Markus Karg > - Renamed contents() to testStreamContents() > > Signed-off-by: Markus Karg > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/a507fd77...e76caa46 Please keep this draft open, it will be continued after other PRs are merged. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From bpb at openjdk.java.net Fri Oct 8 16:46:13 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 8 Oct 2021 16:46:13 GMT Subject: Integrated: 8233749: Files.exists javadoc doesn't mention eating IOException In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:05:24 GMT, Brian Burkhalter wrote: > Add `@see FileSystemProvider#checkAccess` link per the suggestion in the issue. This pull request has now been integrated. Changeset: 239a35aa Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/239a35aa9166d0cb0b20850e1b52ad23b653d8d0 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8233749: Files.exists javadoc doesn't mention eating IOException Reviewed-by: lancea, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5856 From bpb at openjdk.java.net Fri Oct 8 18:43:30 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 8 Oct 2021 18:43:30 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v5] In-Reply-To: References: Message-ID: > On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274548: Change logic to use WRITEV_MAX ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5831/files - new: https://git.openjdk.java.net/jdk/pull/5831/files/6da2c82e..f03fc290 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=03-04 Stats: 95 lines in 4 files changed: 70 ins; 21 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5831/head:pull/5831 PR: https://git.openjdk.java.net/jdk/pull/5831 From bpb at openjdk.java.net Fri Oct 8 18:50:12 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 8 Oct 2021 18:50:12 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v5] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 18:43:30 GMT, Brian Burkhalter wrote: >> On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274548: Change logic to use WRITEV_MAX v4 was verified to pass the test included in this PR on Linux-aarch64, Linux-x64, macOS 10.15.7 and 11.6, and Windows (Server 2016). ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From bpb at openjdk.java.net Fri Oct 8 21:11:36 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 8 Oct 2021 21:11:36 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v6] In-Reply-To: References: Message-ID: > On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274548: Minor restructuring of get_darwin_version() and writevMax() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5831/files - new: https://git.openjdk.java.net/jdk/pull/5831/files/f03fc290..e44a468c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=04-05 Stats: 18 lines in 1 file changed: 8 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5831/head:pull/5831 PR: https://git.openjdk.java.net/jdk/pull/5831 From github.com+6776231+talden at openjdk.java.net Sat Oct 9 03:19:09 2021 From: github.com+6776231+talden at openjdk.java.net (Talden) Date: Sat, 9 Oct 2021 03:19:09 GMT Subject: RFR: 8274811: Remove superfluous use of boxing in java.base In-Reply-To: References: Message-ID: On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov wrote: > Usages of primitive types should be preferred and makes code easier to read. > Similar cleanups: > 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop > 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4135: > 4133: if (date != null) { > 4134: if (date.matches("\\d\\d\\d\\d\\/\\d\\d\\/\\d\\d")) { > 4135: c.set(Integer.parseInt(date.substring(0, 4)), Could this, and several of the other cases identified in this PR, be replaced with a call to the `Integer.parseInt(CharSequence, int, int, int)` method to also avoid the String allocation? Though there are enough other places in the JDK where this opportunity seems valuable that maybe it warrants a tracking issue of its own. ------------- PR: https://git.openjdk.java.net/jdk/pull/5481 From alanb at openjdk.java.net Sat Oct 9 07:21:10 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 9 Oct 2021 07:21:10 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v6] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 21:11:36 GMT, Brian Burkhalter wrote: >> On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274548: Minor restructuring of get_darwin_version() and writevMax() src/java.base/unix/native/libnio/ch/IOUtil.c line 216: > 214: // overflows a 32-bit integer. > 215: // > 216: int darwin_version = get_darwin_version(); What you would think about dropping the OS version and just return Integer.MAX_VALUE on macOS? That would align with the EINVAL documented in the man page on all versions. In passing, an inconsistency has kept into the native code. In some places we are using ifdef __APPLE__ and in others ifdef MACOX. We should probably clean this up. ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From github.com+1701815+mkarg at openjdk.java.net Sun Oct 10 08:58:12 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 10 Oct 2021 08:58:12 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review. >> >> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are: >> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. >> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides. >> >> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. >> >> I encourage everybody to discuss this draft: >> * Are there valid arguments for *not* doing this change? >> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`? >> * How to go on from here: What is missing to get this ready for an actual review? > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Draft: Eliminated duplicate code using lambda expressions > - Draft: Use blocking mode also for target channel Work on this draft will be continued as soon as depenency PRs are resolved. Please keep this issue open. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From shade at openjdk.java.net Mon Oct 11 13:40:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 13:40:10 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v7] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 17:09:06 GMT, Markus KARG wrote: >> Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. >> >> This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. >> >> *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Removed Javadoc > > Signed-off-by: Markus Karg This still looks good to me. Is there anything left to do with this test? I don't see what prevents us from integrating it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From bpb at openjdk.java.net Mon Oct 11 15:54:12 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 11 Oct 2021 15:54:12 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v6] In-Reply-To: References: Message-ID: On Sat, 9 Oct 2021 07:17:55 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274548: Minor restructuring of get_darwin_version() and writevMax() > > src/java.base/unix/native/libnio/ch/IOUtil.c line 216: > >> 214: // overflows a 32-bit integer. >> 215: // >> 216: int darwin_version = get_darwin_version(); > > What you would think about dropping the OS version and just return Integer.MAX_VALUE on macOS? That would align with the EINVAL documented in the man page on all versions. > > In passing, an inconsistency has kept into the native code. In some places we are using ifdef __APPLE__ and in others ifdef MACOX. We should probably clean this up. I'm find with dropping the OS version check on macOS and removing the Darwin version function. I also noticed the inconsistency in the APPLE and MACOSX symbolic constants. There's also another one like ALL_BSD_SOURCE. I don't know whether we consider that redundant as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From alanb at openjdk.java.net Mon Oct 11 16:06:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 11 Oct 2021 16:06:08 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v6] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 15:50:46 GMT, Brian Burkhalter wrote: > I'm find with dropping the OS version check on macOS and removing the Darwin version function. I think it will align with the man page and remove any questions as to why this is macOS version specific. > I also noticed the inconsistency in the APPLE and MACOSX symbolic constants. There's also another one like ALL_BSD_SOURCE. I don't know whether we consider that redundant as well. We can look at this in a separate issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From bpb at openjdk.java.net Mon Oct 11 16:17:47 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 11 Oct 2021 16:17:47 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v7] In-Reply-To: References: Message-ID: > On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274548: On macOS, remove dependence on Darwin version in native writevMax() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5831/files - new: https://git.openjdk.java.net/jdk/pull/5831/files/e44a468c..079ce195 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5831&range=05-06 Stats: 43 lines in 1 file changed: 1 ins; 35 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5831/head:pull/5831 PR: https://git.openjdk.java.net/jdk/pull/5831 From bpb at openjdk.java.net Mon Oct 11 16:50:09 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 11 Oct 2021 16:50:09 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v6] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 16:03:10 GMT, Alan Bateman wrote: >> I'm find with dropping the OS version check on macOS and removing the Darwin version function. >> >> I also noticed the inconsistency in the APPLE and MACOSX symbolic constants. There's also another one like ALL_BSD_SOURCE. I don't know whether we consider that redundant as well. > >> I'm find with dropping the OS version check on macOS and removing the Darwin version function. > > I think it will align with the man page and remove any questions as to why this is macOS version specific. > > >> I also noticed the inconsistency in the APPLE and MACOSX symbolic constants. There's also another one like ALL_BSD_SOURCE. I don't know whether we consider that redundant as well. > > We can look at this in a separate issue. ... and dropping the OS version check leaves fewer moving parts. On the conditional compilation symbolic constants I filed JDK-8275070. ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From alanb at openjdk.java.net Mon Oct 11 18:39:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 11 Oct 2021 18:39:14 GMT Subject: RFR: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 [v7] In-Reply-To: References: Message-ID: <-Gsyg7dKnSFP_A8ZRpRsAqTivf41vchXa9T-bHFVMtM=.d436047c-1ea3-46ed-a024-f0140650354a@github.com> On Mon, 11 Oct 2021 16:17:47 GMT, Brian Burkhalter wrote: >> On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274548: On macOS, remove dependence on Darwin version in native writevMax() Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From bpb at openjdk.java.net Tue Oct 12 02:15:54 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 12 Oct 2021 02:15:54 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v7] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 17:09:06 GMT, Markus KARG wrote: >> Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. >> >> This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. >> >> *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Removed Javadoc > > Signed-off-by: Markus Karg Marked as reviewed by bpb (Reviewer). The methods from line 161 onward, starting with `createRandomBytes()` would benefit from a one-line comment. test/jdk/java/nio/channels/Channels/TransferTo.java line 69: > 67: private static final Random RND = RandomFactory.getRandom(); > 68: > 69: @DataProvider It would be good to have a comment here equivalent to the other public methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From bpb at openjdk.java.net Tue Oct 12 15:29:57 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 12 Oct 2021 15:29:57 GMT Subject: Integrated: 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 00:00:00 GMT, Brian Burkhalter wrote: > On macOS, handle the case where `writev()` is given an array of `struct iovec` the sum of whose `iov_len` fields overflows `INT_MAX`. This pull request has now been integrated. Changeset: 07b1f1c2 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/07b1f1c282ee0a7df6a6b0f240962a032ea3a413 Stats: 173 lines in 4 files changed: 169 ins; 1 del; 3 mod 8274548: (fc) FileChannel gathering write fails with IOException "Invalid argument" on macOS 11.6 Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5831 From mcimadamore at openjdk.java.net Tue Oct 12 16:37:57 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Oct 2021 16:37:57 GMT Subject: RFR: 8275063: Implementation of Memory Access API (Second incubator) Message-ID: This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. [1] - https://openjdk.java.net/jeps/419 ------------- Commit messages: - Fix issues with Aarch64 VaList implementation - Drop argument type profiling for removed `MemoryAccess` class - Add missing files - Tweak javadoc for MemeorySegment/MemoryAddress::setUtf8String - Initial push from panama/foreign Changes: https://git.openjdk.java.net/jdk/pull/5907/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275063 Stats: 14262 lines in 186 files changed: 6583 ins; 5144 del; 2535 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Tue Oct 12 16:37:57 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Oct 2021 16:37:57 GMT Subject: RFR: 8275063: Implementation of Memory Access API (Second incubator) In-Reply-To: References: Message-ID: <-PiXRcdXSgem16bbZeDqOiJpOJu7FT_FaB8nFYHoGig=.91ba78cb-66d9-4ed3-82e9-184ab4b2616c@github.com> On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 This PR contains mainly API changes. We have tried to simplify the API, by removing redundant classes and moving functionalities where they belong. Below we list the main changes introduced in this PR. A big thanks to all who helped along the way: @briangoetz, @ChrisHegarty, @FrauBoes, @iwanowww, @JornVernee, @PaulSandoz, @sundararajana and @rose00. ### Value layouts and carriers This is perhaps the biggest change in the API, which has a knock-on effect in other areas as well. In the past, a value layout used to be a fairly *neutral* description of a piece of memory containing a scalar value. A value layout has a size, alignment and endianness. Since a value layout contains no information on *how* the value is to be dereferenced by Java clients, said clients have to specify a *carrier* when obtaining a var handle from a value layout. In this iteration, we have decided to attach carrier types to value layouts - so, in addition to size, alignment and endianness, all value layouts now have a `carrier` accessor, which returns a `j.l.Class`. You will find several hand-specialized version of `ValueLayout`, one for each main carrier type (e.g. `ValueLayout.OfInt` for the `int` carrier). Attaching carrier information to layouts simplifies the API in many ways: * When obtaining a var handle from a layout, it is no longer necessary to provide a carrier; the layout in fact contains all the necessary information for the dereference operation to occur. * Similarly, when linking downcall method handles, the `MethodType` parameter is no longer necessary, as now carrier information can be inferred from the provided `FunctionDescriptor`. * We can express dereference operations in a more general fashion - e.g. `get(ValueLayout.OfInt)` instead of `getInt(ByteOrder)`. Note how the new form is more *complete*. This iteration also adds support for `boolean` and `MemoryAddress` carriers in memory access var handles. ### Layout attributes To help the `CLinker` distinguish between a 32-bit layout modelling to a C `int` and a similar layout modelling a C `float` we have in the past resorted to *layout attributes* - that is, we injected custom classification information in layouts, and then required clients working with the `CLinker` API to only work with such augmented layouts. Because of the changes described above, this is no longer necessary: a layout is always associated with a Java carrier, so the `CLinker` can always disambiguate between `ValueLayout.OfInt` and `ValueLayout.OfFloat` even though they have the same size. For this reason, API support for custom layout attributes has been dropped in this iteration. Similarly, platform-dependent layout constants in `CLinker` have been removed; clients interacting with the foreign linker can simply use the basic layout constants defined in `ValueLayout` (e.g. `JAVA_INT`, `JAVA_FLOAT`, ...) - which is not too different from using the JNI types `jint` and `jfloat`. Of course tools (such as `jextract`) are free to define *custom* layouts which model C type for a specific platform. ### Memory dereference Previous iterations of the API provided ready-made dereference operations as static methods in the `MemoryAccess` class. This class is now removed, and all the dereference operations have been moved to `MemorySegment` and `MemoryAddress`. As mentioned before, the new dereference operations have a new form. Instead of: MemorySegment segment = ... MemoryAccess.getIntAtOffset(segment, /*offset */ 100, /* endianness */ ByteOrder.nativeOrder()); The new API works as follows: MemorySegment segment = ... int val = segment.get(JAVA_INT, /*offset */ 100); Note that the new dereference method is not static, and that parameters such as endianness are now omitted, since clients can just specify the value layout they want to work with. Also, since the new dereference methods are not static, we no longer need the workaround to enable VM argument type profiling (this was necessary to make static methods in `MemoryAccess` class perform reasonably well in the face of profile pollution). The same dereference operations are also available in `MemoryAddress`; when working with native code it might be necessary to dereference a raw pointer. In Java 17, to write a basic comparator function for qsort, the following code is needed: static int qsortCompare(MemoryAddress addr1, MemoryAddress addr2) { return MemoryAccess.getIntAtOffset(MemorySegment.globalNativeSegment(), addr1.toRawLongValue()) - MemoryAccess.getIntAtOffset(MemorySegment.globalNativeSegment(), addr2.toRawLongValue()); With the proposed changes, the above code simplifies to: static int qsortCompare(MemoryAddress addr1, MemoryAddress addr2) { return addr1.get(C_INT, 0) - addr2.get(C_INT, 0); } Which is far more readable. Note that dereferencing a memory address is still a potentially unsafe operation, as an address has no spatia/temporall bounds. For this reason, dereference operation on `MemoryAddress` are marked as *restricted*. ### Memory copy This iteration adds more support for copying Java arrays to and from memory segments. In Java 17, it is possible to copy a Java array into a memory segment, as follows: int[] array = .... MemorySegment segment = ... MemorySegment heapView = MemorySegment.ofArray(array); segment.asSlice(startSegmentOffset, nelems * 4) .copyFrom(heapView.asSlice(startArrayOffset * 4, nelems * 4)) This code snippet is suboptimal for several reasons: * three temporary segments have to be created: the heap view, plus the two slices * note how the code has to carefully slice the source/target segment to make sure that only the desired elements are copied, and at the desired target offset in the segment. * offset in arrays is expressed in elements, whereas offset in segments is expressed in bytes - which calls for potential mistakes. * it is not possible to specify custom endianness/alignment for the copy operation With the changes in this PR, the above code becomes: int[] array = .... MemorySegment segment = ... MemorySegment.copy(array, startArrayOffset, segment, JAVA_INT, startSegmentOffset, nelems); The above code is much simpler, with less potential for mistakes. Also, the extra value layout allows client to inject additional alignment constraints and endianness (if required). ### Role of `MemoryAddress` In Java 17, `MemoryAddress` has a scope accessor. This is useful when reasoning about an address obtained from a memory segment, but is far less useful when thinking about an address received from a native call. While it is possible to model the latter as an address associated with the *global scope*, `MemoryAddress` supports several operations which allow clients to attach spatial and temporal bounds to an address, turning it into a `MemorySegment`. If the address already has a scope, the semantics of some of these operation becomes confusing. For this reason, in this iteration `MemoryAddress` is only used to model raw native addresses. There is no scope associated with a memory address - dereferencing a raw address is always unsafe. This change brings more clarity to API, as `MemoryAddress` is nothing but a simple wrapper around a `long` value. This also means that obtaining a `MemoryAddress` from a heap segment is no longer a possibility; in other words, clients that don't care about native interop should probably just use `MemorySegment` and forget about `MemoryAddress`. ### Downcall method handle safety In Java 17, by-reference parameters to downcall method handles are passed as `MemoryAddress` arguments. This means that e.g. passing a segment by-reference requires a conversion (from segment to memory address, using `MemorySegment::address`). This conversion is lossy, as we lose information about the original memory segment (spatial and temporal bounds). As a result, passing parameter by-reference to downcall method handle is less safe. The changes described in this PR introduce stronger safety guarantees for by-reference parameters. The `CLinker` will now map any such parameter to the `Addressable` type - a common super interface of all things that can be passed by reference. This means clients can pass a memory segment *directly* to a downcall method handle, no conversion required. Because of that, the `CLinker` runtime can make sure that e.g. arguments passed by reference are kept alive for the entire duration of the native call. ### Native symbols In Java 17, looking up a symbol on a native library is done using the `SymbolLookup` interface. This interface used to return a plain `MemoryAddress` (the address of the native function). Given the changes described above, `MemoryAddress` is no longer a great choice: * a `MemoryAddress` now models a raw native memory address, and has no scope * a `MemoryAddress` can be easily dereferenced* For this reason, a new abstraction is added, namely `NativeSymbol`, which is used to model the entry point of a symbol (a function or a global variable) in a native library. A native symbol is `Addressable`, has a name and a resource scope. Since native symbols have a scope, the `CLinker` runtime can make sure that the scope of the native symbol corresponding to the native function being executed cannot be closed prematurely. This effectively allows clients to support safe library loading abstractions which support [deterministic library unloading](https://github.com/sundararajana/panama-jextract-samples/blob/master/dlopen/Dlopen.java). Additionally, we have tweaked the `CLinker::upcallStub` method to also return an *anonymous* `NativeSymbol`, rather than a raw `MemoryAddress`. ### Resource scope tweaks This PR removes the distinction between *implicit* and *explicit* scopes. Now all scopes (except for the *global scope*) are closeable, and can be associated with a `Cleaner`, if required. Another change in the resource scope API is in how temporal scope dependencies are handled. In Java 17 scopes could be acquired and released: MemorySegment segment = ... ResourceScope.Handle segmentHandle = segment.scope().acquire(); try { } finally { segment.scope().release(segmentHandle); } This PR removes the `ResourceScope::acquire` and `ResourceScope::release` methods, and allows instead to capture dependencies between scopes in a more explicit fashion: MemorySegment segment = ... try (ResourceScope criticalScope = ResourceScope.newConfinedScope()) { criticalScope.keepAlive(segment.scope()); } API javadoc: http://cr.openjdk.java.net/~mcimadamore/8275064/javadoc/jdk/incubator/foreign/package-summary.html Specdiff: http://cr.openjdk.java.net/~mcimadamore/8275064/specdiff_out/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From erikj at openjdk.java.net Tue Oct 12 17:03:52 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 12 Oct 2021 17:03:52 GMT Subject: RFR: 8275063: Implementation of Memory Access API (Second incubator) In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5907 From bpb at openjdk.java.net Tue Oct 12 18:06:06 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 12 Oct 2021 18:06:06 GMT Subject: RFR: 8275149: (ch) ReadableByteChannel returned by Channels.newChannel(InputStream) throws ReadOnlyBufferException Message-ID: <1fgX6lPHjxvID9zlOAsJuA2BYAMHG9kOMjBkfkOJXx8=.2f441a99-3ca2-435b-9452-fe27322ad182@github.com> This small change would modify `java.nio.channels.Channels$ReadableByteChannelImpl.read(ByteBuffer)` to throw an `IllegalArgumentException` if the `ByteBuffer` parameter is read-only as required by its specification instead of the `ReadOnlyBufferException` currently thrown. ------------- Commit messages: - 8275149: throw RuntimeException if IAE not thrown - 8275149: (ch) ReadableByteChannel returned by Channels.newChannel(InputStream) throws ReadOnlyBufferException Changes: https://git.openjdk.java.net/jdk/pull/5914/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5914&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275149 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5914.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5914/head:pull/5914 PR: https://git.openjdk.java.net/jdk/pull/5914 From alanb at openjdk.java.net Tue Oct 12 18:18:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 12 Oct 2021 18:18:53 GMT Subject: RFR: 8275149: (ch) ReadableByteChannel returned by Channels.newChannel(InputStream) throws ReadOnlyBufferException In-Reply-To: <1fgX6lPHjxvID9zlOAsJuA2BYAMHG9kOMjBkfkOJXx8=.2f441a99-3ca2-435b-9452-fe27322ad182@github.com> References: <1fgX6lPHjxvID9zlOAsJuA2BYAMHG9kOMjBkfkOJXx8=.2f441a99-3ca2-435b-9452-fe27322ad182@github.com> Message-ID: On Tue, 12 Oct 2021 17:56:59 GMT, Brian Burkhalter wrote: > This small change would modify `java.nio.channels.Channels$ReadableByteChannelImpl.read(ByteBuffer)` to throw an `IllegalArgumentException` if the `ByteBuffer` parameter is read-only as required by its specification instead of the `ReadOnlyBufferException` currently thrown. Looks okay but it is a behavior change. We should check if there is anything dependent on the existing exception. We'll need a RN, maybe a CSR. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5914 From bpb at openjdk.java.net Tue Oct 12 18:21:51 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 12 Oct 2021 18:21:51 GMT Subject: RFR: 8275149: (ch) ReadableByteChannel returned by Channels.newChannel(InputStream) throws ReadOnlyBufferException In-Reply-To: <1fgX6lPHjxvID9zlOAsJuA2BYAMHG9kOMjBkfkOJXx8=.2f441a99-3ca2-435b-9452-fe27322ad182@github.com> References: <1fgX6lPHjxvID9zlOAsJuA2BYAMHG9kOMjBkfkOJXx8=.2f441a99-3ca2-435b-9452-fe27322ad182@github.com> Message-ID: On Tue, 12 Oct 2021 17:56:59 GMT, Brian Burkhalter wrote: > This small change would modify `java.nio.channels.Channels$ReadableByteChannelImpl.read(ByteBuffer)` to throw an `IllegalArgumentException` if the `ByteBuffer` parameter is read-only as required by its specification instead of the `ReadOnlyBufferException` currently thrown. Do you think it would be better instead to change the specification to say it throws `ReadOnlyBufferException` instead of IAE, i.e., to match existing behavior? ------------- PR: https://git.openjdk.java.net/jdk/pull/5914 From alanb at openjdk.java.net Tue Oct 12 18:31:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 12 Oct 2021 18:31:50 GMT Subject: RFR: 8275149: (ch) ReadableByteChannel returned by Channels.newChannel(InputStream) throws ReadOnlyBufferException In-Reply-To: References: <1fgX6lPHjxvID9zlOAsJuA2BYAMHG9kOMjBkfkOJXx8=.2f441a99-3ca2-435b-9452-fe27322ad182@github.com> Message-ID: On Tue, 12 Oct 2021 18:18:49 GMT, Brian Burkhalter wrote: > Do you think it would be better instead to change the specification to say it throws `ReadOnlyBufferException` instead of IAE, i.e., to match existing behavior? I checked a few of the channel implementations and they throw the expected IAE. It looks like the only ReadableByteChannel that throws ReadOnlyBufferException is the implementation returned by newChannel. So I think the change is okay and not risky. We should try to see if there is any code that is catching ReadOnlyBufferException. ------------- PR: https://git.openjdk.java.net/jdk/pull/5914 From mcimadamore at openjdk.java.net Tue Oct 12 20:51:02 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Oct 2021 20:51:02 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v2] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix TestLinkToNativeRBP test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/be0dd36e..23f69054 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=00-01 Stats: 7 lines in 1 file changed: 1 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From psandoz at openjdk.java.net Wed Oct 13 00:06:03 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 13 Oct 2021 00:06:03 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v2] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 20:51:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/419 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix TestLinkToNativeRBP test Like with previous reviews of code for Panama JEPs there are not many comments on this PR, since prior reviews occurred for PRs in the panama-foreign repo. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 77: > 75: * Furthermore, if the function descriptor's return layout is a group layout, the resulting downcall method handle accepts > 76: * an extra parameter of type {@link SegmentAllocator}, which is used by the linker runtime to allocate the > 77: * memory region associated with the struct returned by the downcall method handle. Suggestion: * memory region associated with the struct returned by the downcall method handle. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 88: > 86: * in which the specialized signature of a given variable arity callsite is described in full. Alternatively, > 87: * if the foreign library allows it, clients might also be able to interact with variable arity methods > 88: * using by passing a trailing parameter of type {@link VaList}. Suggestion: * by passing a trailing parameter of type {@link VaList}. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 145: > 143: * Lookup a symbol in the standard libraries associated with this linker. > 144: * The set of symbols available for lookup is unspecified, as it depends on the platform and on the operating system. > 145: * @return a linker-specific library lookup which is suitable to find symbols in the standard libraries associated with this linker. Suggestion: * @return a symbol in the standard libraries associated with this linker. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java line 93: > 91: Objects.requireNonNull(argLayouts); > 92: Arrays.stream(argLayouts).forEach(Objects::requireNonNull); > 93: return new FunctionDescriptor(null, argLayouts); We need to clone `argLayouts`, otherwise the user can modify the contents. Internally, using `List.of` is useful, since it does the cloning and null checks, and that is the type that is returned. Also `argumentLayouts` uses `Arrays.asList` which supports modification of the contents. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java line 394: > 392: *

> 393: * The returned allocator might throw an {@link OutOfMemoryError} if the total memory allocated with this allocator > 394: * exceeds the arena size, or the system capacity. Furthermore, the returned allocator is not thread safe, and all The "the returned allocator is not thread safe" contradicts the prior sentence "An allocator associated with a shared resource scope is thread-safe and allocation requests may be performed concurrently". Perhaps just say: "

The returned allocator is not thread safe if the given scope is a shared scope. Concurrent allocation needs to be guarded with synchronization primitives. " src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 260: > 258: > 259: @Override > 260: public final MemorySegment asOverlappingSlice(MemorySegment other) { Please ignore these comments if you wish. Adding `max() // exclusive` to complement `min()` might be useful. In these cases i find it easier to sort the segments e.g. `var a = this; var b = other; if (a.min() > b.min()) { // swap a and b }` then the subsequent logic tends to get simpler e.g. overlap test is `if (b.min() < a.max())`, `segmentOffset` is always +ve. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java line 100: > 98: do { > 99: value = (int)ASYNC_RELEASE_COUNT.getVolatile(this); > 100: } while (!ASYNC_RELEASE_COUNT.compareAndSet(this, value, value + 1)); Use `getAndAdd` (and ignore the return value). ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From bpb at openjdk.java.net Wed Oct 13 02:13:03 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 13 Oct 2021 02:13:03 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel Message-ID: Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. ------------- Commit messages: - 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel Changes: https://git.openjdk.java.net/jdk/pull/5922/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5922&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4619075 Stats: 449 lines in 2 files changed: 437 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5922.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5922/head:pull/5922 PR: https://git.openjdk.java.net/jdk/pull/5922 From bpb at openjdk.java.net Wed Oct 13 02:13:03 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 13 Oct 2021 02:13:03 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 02:04:37 GMT, Brian Burkhalter wrote: > Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. If this proposal appears promising, a corresponding CSR will be filed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From alanb at openjdk.java.net Wed Oct 13 07:17:52 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 13 Oct 2021 07:17:52 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 02:04:37 GMT, Brian Burkhalter wrote: > Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. src/java.base/share/classes/java/nio/channels/Channels.java line 271: > 269: * @return A new readable byte channel > 270: */ > 271: public static ScatteringByteChannel newChannel(InputStream in) { This looks like a binary incompatible change, are you sure that existing code won't fail at runtime with NoSuchMethodError? ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From mcimadamore at openjdk.java.net Wed Oct 13 12:07:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 13 Oct 2021 12:07:58 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v3] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/23f69054..d6bf27ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Wed Oct 13 12:48:06 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 13 Oct 2021 12:48:06 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v4] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/d6bf27ff..27e71ee7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=02-03 Stats: 35 lines in 4 files changed: 8 ins; 11 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From bpb at openjdk.java.net Wed Oct 13 16:29:47 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 13 Oct 2021 16:29:47 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 02:04:37 GMT, Brian Burkhalter wrote: > Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. Unfortunately you are correct; I thought I had tested that. In any case, this PR can either be withdrawn, or the proposal changed to add to `Channels` the methods `newGatheringByteChannel` and `newScatteringByteChannel`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From darcy at openjdk.java.net Wed Oct 13 16:47:49 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 13 Oct 2021 16:47:49 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 07:14:21 GMT, Alan Bateman wrote: >> Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. > > src/java.base/share/classes/java/nio/channels/Channels.java line 271: > >> 269: * @return A new readable byte channel >> 270: */ >> 271: public static ScatteringByteChannel newChannel(InputStream in) { > > This looks like a binary incompatible change, are you sure that existing code won't fail at runtime with NoSuchMethodError? Right; covariant overrides are only compatible for instance methods, not static methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From bpb at openjdk.java.net Wed Oct 13 16:58:24 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 13 Oct 2021 16:58:24 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel [v2] In-Reply-To: References: Message-ID: <6hXOF1E9-OkwofoNrL5cKy9DeD-RIMCVwyKB-ywtj8k=.a23f30db-9b07-4a76-9858-01add7901814@github.com> > Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4619075: Change binary incompatible static covariant overrides to new methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5922/files - new: https://git.openjdk.java.net/jdk/pull/5922/files/fd41d0fb..0a4ff249 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5922&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5922&range=00-01 Stats: 103 lines in 2 files changed: 74 ins; 13 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5922.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5922/head:pull/5922 PR: https://git.openjdk.java.net/jdk/pull/5922 From bpb at openjdk.java.net Wed Oct 13 16:58:27 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 13 Oct 2021 16:58:27 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel [v2] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 16:44:32 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/nio/channels/Channels.java line 271: >> >>> 269: * @return A new readable byte channel >>> 270: */ >>> 271: public static ScatteringByteChannel newChannel(InputStream in) { >> >> This looks like a binary incompatible change, are you sure that existing code won't fail at runtime with NoSuchMethodError? > > Right; covariant overrides are only compatible for instance methods, not static methods. I added a number of non-static covariant overrides to `MappedByteBuffer` previously and so overlooked the static issue here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From bpb at openjdk.java.net Wed Oct 13 21:05:26 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 13 Oct 2021 21:05:26 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel [v3] In-Reply-To: References: Message-ID: > Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4619075: Add @since tags to new methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5922/files - new: https://git.openjdk.java.net/jdk/pull/5922/files/0a4ff249..e06b2149 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5922&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5922&range=01-02 Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5922.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5922/head:pull/5922 PR: https://git.openjdk.java.net/jdk/pull/5922 From jiefu at openjdk.java.net Thu Oct 14 07:21:04 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 14 Oct 2021 07:21:04 GMT Subject: RFR: 8275265: java/nio/channels tests needing large heap sizes fail on x86_32 Message-ID: Hi all, java/nio/channels/FileChannel/LargeGatheringWrite.java and java/nio/channels/Channels/ReadXBytes.java fail on x86_32. This is because they require `-Xmx4G` and `-Xmx8G`, which are invalid on 32-bit platforms. So let's exclude them on 32-bit platforms. Thanks. Best regards, Jie ------------- Commit messages: - 8275265: Two java/nio/channels tests fails on x86_32 Changes: https://git.openjdk.java.net/jdk/pull/5942/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5942&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275265 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5942.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5942/head:pull/5942 PR: https://git.openjdk.java.net/jdk/pull/5942 From alanb at openjdk.java.net Thu Oct 14 07:24:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 14 Oct 2021 07:24:50 GMT Subject: RFR: 8275265: java/nio/channels tests needing large heap sizes fail on x86_32 In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 07:12:17 GMT, Jie Fu wrote: > Hi all, > > java/nio/channels/FileChannel/LargeGatheringWrite.java and java/nio/channels/Channels/ReadXBytes.java fail on x86_32. > > This is because they require `-Xmx4G` and `-Xmx8G`, which are invalid on 32-bit platforms. > So let's exclude them on 32-bit platforms. > > Thanks. > Best regards, > Jie Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5942 From jiefu at openjdk.java.net Thu Oct 14 12:14:48 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 14 Oct 2021 12:14:48 GMT Subject: RFR: 8275265: java/nio/channels tests needing large heap sizes fail on x86_32 In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 07:22:07 GMT, Alan Bateman wrote: >> Hi all, >> >> java/nio/channels/FileChannel/LargeGatheringWrite.java and java/nio/channels/Channels/ReadXBytes.java fail on x86_32. >> >> This is because they require `-Xmx4G` and `-Xmx8G`, which are invalid on 32-bit platforms. >> So let's exclude them on 32-bit platforms. >> >> Thanks. >> Best regards, >> Jie > > Marked as reviewed by alanb (Reviewer). Thanks @AlanBateman . Will push it tomorrow if there is no objection. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5942 From alanb at openjdk.java.net Thu Oct 14 14:07:48 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 14 Oct 2021 14:07:48 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 16:26:38 GMT, Brian Burkhalter wrote: > Unfortunately you are correct; I thought I had tested that. In any case, this PR can either be withdrawn, or the proposal changed to add to `Channels` the methods `newGatheringByteChannel` and `newScatteringByteChannel`. Okay, we need to think through whether how useful they might be. There are several other API options here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From bpb at openjdk.java.net Thu Oct 14 14:57:48 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 14 Oct 2021 14:57:48 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel [v3] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 21:05:26 GMT, Brian Burkhalter wrote: >> Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 4619075: Add @since tags to new methods One other possibility I had thought of was to change `newChannel(InputStream)` and `newChannel(OutputStream)` to respectively return a `ScatteringByteChannel` and a `GatheringByteChannel` without changing the return types of the methods from their current declarations and instead calling out what is in fact returned in the javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From bpb at openjdk.java.net Thu Oct 14 15:26:46 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 14 Oct 2021 15:26:46 GMT Subject: RFR: 8275265: java/nio/channels tests needing large heap sizes fail on x86_32 In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 07:12:17 GMT, Jie Fu wrote: > Hi all, > > java/nio/channels/FileChannel/LargeGatheringWrite.java and java/nio/channels/Channels/ReadXBytes.java fail on x86_32. > > This is because they require `-Xmx4G` and `-Xmx8G`, which are invalid on 32-bit platforms. > So let's exclude them on 32-bit platforms. > > Thanks. > Best regards, > Jie Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5942 From jiefu at openjdk.java.net Thu Oct 14 23:16:59 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 14 Oct 2021 23:16:59 GMT Subject: RFR: 8275265: java/nio/channels tests needing large heap sizes fail on x86_32 In-Reply-To: References: Message-ID: <7vkyrOuGIEKcU-Wy41XFKqRdiQL9-b8WM1gKlR93z98=.061e8f5b-b8fa-4fc7-8eef-9ee56bb55639@github.com> On Thu, 14 Oct 2021 15:24:15 GMT, Brian Burkhalter wrote: >> Hi all, >> >> java/nio/channels/FileChannel/LargeGatheringWrite.java and java/nio/channels/Channels/ReadXBytes.java fail on x86_32. >> >> This is because they require `-Xmx4G` and `-Xmx8G`, which are invalid on 32-bit platforms. >> So let's exclude them on 32-bit platforms. >> >> Thanks. >> Best regards, >> Jie > > Marked as reviewed by bpb (Reviewer). Thanks @bplb . ------------- PR: https://git.openjdk.java.net/jdk/pull/5942 From jiefu at openjdk.java.net Thu Oct 14 23:16:59 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 14 Oct 2021 23:16:59 GMT Subject: Integrated: 8275265: java/nio/channels tests needing large heap sizes fail on x86_32 In-Reply-To: References: Message-ID: <8MHK6PkKW62aydPpBhwc9MgVotY7L4BNsxFzZiynky0=.d005f67e-efd6-4acf-a421-4151ee14c2d4@github.com> On Thu, 14 Oct 2021 07:12:17 GMT, Jie Fu wrote: > Hi all, > > java/nio/channels/FileChannel/LargeGatheringWrite.java and java/nio/channels/Channels/ReadXBytes.java fail on x86_32. > > This is because they require `-Xmx4G` and `-Xmx8G`, which are invalid on 32-bit platforms. > So let's exclude them on 32-bit platforms. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: 9623d5bb Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/9623d5bb46d14018a2b777fb7ffed6c66d912c84 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod 8275265: java/nio/channels tests needing large heap sizes fail on x86_32 Reviewed-by: alanb, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5942 From mcimadamore at openjdk.java.net Fri Oct 15 16:54:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 15 Oct 2021 16:54:58 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v5] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * Fix javadoc issue in VaList * Fix bug in concurrent logic for shared scope acquire ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/27e71ee7..5ed94c30 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=03-04 Stats: 10 lines in 2 files changed: 2 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Fri Oct 15 16:56:08 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 15 Oct 2021 16:56:08 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v5] In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 16:54:58 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/419 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > * Fix javadoc issue in VaList > * Fix bug in concurrent logic for shared scope acquire src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java line 138: > 136: ResourceCleanup prev = (ResourceCleanup) FST.getAcquire(this); > 137: cleanup.next = prev; > 138: ResourceCleanup newSegment = (ResourceCleanup) FST.compareAndExchangeRelease(this, prev, cleanup); In this place we can actually overwrite CLOSED_LIST (if getAcquired has seen such value). While this particular add will fail later on (since we check witness), another concurrent add might then pass, since it sees a value other than CLOSED_LIST (which is supposed to be a terminal state). Also, after consulting with @DougLea and @shipilev - it seems like using volatile semantics is the way to go here. This should fix a spurious (and very rare) failure on TestResourceScope on arm64. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From bpb at openjdk.java.net Fri Oct 15 23:01:57 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 15 Oct 2021 23:01:57 GMT Subject: Integrated: 8275149: (ch) ReadableByteChannel returned by Channels.newChannel(InputStream) throws ReadOnlyBufferException In-Reply-To: <1fgX6lPHjxvID9zlOAsJuA2BYAMHG9kOMjBkfkOJXx8=.2f441a99-3ca2-435b-9452-fe27322ad182@github.com> References: <1fgX6lPHjxvID9zlOAsJuA2BYAMHG9kOMjBkfkOJXx8=.2f441a99-3ca2-435b-9452-fe27322ad182@github.com> Message-ID: On Tue, 12 Oct 2021 17:56:59 GMT, Brian Burkhalter wrote: > This small change would modify `java.nio.channels.Channels$ReadableByteChannelImpl.read(ByteBuffer)` to throw an `IllegalArgumentException` if the `ByteBuffer` parameter is read-only as required by its specification instead of the `ReadOnlyBufferException` currently thrown. This pull request has now been integrated. Changeset: 7fc3a8d0 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/7fc3a8d052bfb8d31fedec56f72b10a40ba7bf83 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod 8275149: (ch) ReadableByteChannel returned by Channels.newChannel(InputStream) throws ReadOnlyBufferException Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5914 From duke at openjdk.java.net Sat Oct 16 08:37:09 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 16 Oct 2021 08:37:09 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v8] In-Reply-To: References: Message-ID: > Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. > > This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. > > *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* Markus KARG has updated the pull request incrementally with two additional commits since the last revision: - Added code comments for private methods Signed-off-by: Markus Karg - Added code comment for public method Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5421/files - new: https://git.openjdk.java.net/jdk/pull/5421/files/54b7438b..137d1f4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=06-07 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5421/head:pull/5421 PR: https://git.openjdk.java.net/jdk/pull/5421 From duke at openjdk.java.net Sat Oct 16 08:37:10 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 16 Oct 2021 08:37:10 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v7] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 02:12:25 GMT, Brian Burkhalter wrote: > The methods from line 161 onward, starting with `createRandomBytes()` would benefit from a one-line comment. Done in https://github.com/openjdk/jdk/pull/5421/commits/137d1f4ef42c3da5192874047c0a077f031ef74c. > test/jdk/java/nio/channels/Channels/TransferTo.java line 69: > >> 67: private static final Random RND = RandomFactory.getRandom(); >> 68: >> 69: @DataProvider > > It would be good to have a comment here equivalent to the other public methods. Done in https://github.com/openjdk/jdk/pull/5421/commits/5c5317f18659754b673fcc19160acec5b1a11938. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From mcimadamore at openjdk.java.net Sat Oct 16 11:11:59 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Sat, 16 Oct 2021 11:11:59 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v6] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - * use `invokeWithArguments` to simplify new test - Add test for liveness check with high-aririty downcalls (make sure that if an exception occurs in a downcall because of liveness, ref count of other resources are left intact). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/5ed94c30..a4db81fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=04-05 Stats: 39 lines in 2 files changed: 39 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From duke at openjdk.java.net Sat Oct 16 13:30:47 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 16 Oct 2021 13:30:47 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v4] In-Reply-To: <5v_LSpUgg5nGalLhfC8e53sLkX0xlh39rE3FFsWnkYQ=.25b7ea6d-b5cb-485b-b7a6-a85f79b2be3a@github.com> References: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> <5v_LSpUgg5nGalLhfC8e53sLkX0xlh39rE3FFsWnkYQ=.25b7ea6d-b5cb-485b-b7a6-a85f79b2be3a@github.com> Message-ID: On Fri, 1 Oct 2021 15:08:42 GMT, Markus KARG wrote: > On a process level, it would be better to wait for feedback on changes before integrating. This is especially so as a sponsor has to be comfortable with the content. Ideally at least one approval should be associated with the most recent commit. @bplb I don't want to make it wrong again, but I think this time I am right that I can integrate *right now* (even I pushed more comments requested by you), as you approved this PR *directly after* you requested that comments. If not, please directly tell me how to otherwise understand your approval. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From ecki at zusammenkunft.net Sun Oct 17 02:56:17 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 17 Oct 2021 02:56:17 +0000 Subject: InnocuousThread names (was: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride) In-Reply-To: References: <2B573F3A-49B4-48B5-B488-61748D216754@amazon.com> Message-ID: Apropos InnocousThread backporting - I Wonder if we should remove the auto threadname infrastructure and only create properly named threads. The generic name seems to be rather confusing and it seems it is only used in an NIO Pool, where a thread-name should be set, anyway? https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L86 Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: jdk8u-dev im Auftrag von Zhengyu Gu Gesendet: Sunday, October 17, 2021 1:39:12 AM An: Hohensee, Paul ; jdk8u-dev Betreff: Re: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride Thanks, Paul -Zhengyu On 10/15/21 17:30, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Tuesday, October 5, 2021 at 8:12 AM > To: jdk8u-dev > Subject: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride > > This backport is for parity with Oracle 8u321. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190482 > Webrev: http://hg.openjdk.java.net/jdk/jdk/rev/5e7cf99b1303 > > The original patch does not apply cleanly. There is not newThread(String > name, Runnable target) method in 8u, so discard this part of change. > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8190482-8u/webrev.00/ > > > Thanks, > > -Zhengyu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Sun Oct 17 03:24:17 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 17 Oct 2021 03:24:17 +0000 Subject: (ch) InnocuousThread names In-Reply-To: References: <2B573F3A-49B4-48B5-B488-61748D216754@amazon.com> Message-ID: Looking at the code some more I wonder: * if defaultThreadFactoty should use a Thread group for the pool or at least for NIO? * If it can skip the security manager check and use InnocousThread in all cases (to avoid ThreadLocals - not sure if some encode cache is hurt by it?) * If it can skip the priveledged call as IThread does that itself. https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L76 -- http://bernd.eckenfels.net ________________________________ Von: Bernd Eckenfels Gesendet: Sunday, October 17, 2021 4:56:17 AM An: OpenJDK Dev list ; nio-dev at openjdk.java.net Betreff: InnocuousThread names (was: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride) Apropos InnocousThread backporting - I Wonder if we should remove the auto threadname infrastructure and only create properly named threads. The generic name seems to be rather confusing and it seems it is only used in an NIO Pool, where a thread-name should be set, anyway? https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L86 Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: jdk8u-dev im Auftrag von Zhengyu Gu Gesendet: Sunday, October 17, 2021 1:39:12 AM An: Hohensee, Paul ; jdk8u-dev Betreff: Re: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride Thanks, Paul -Zhengyu On 10/15/21 17:30, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Tuesday, October 5, 2021 at 8:12 AM > To: jdk8u-dev > Subject: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride > > This backport is for parity with Oracle 8u321. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190482 > Webrev: http://hg.openjdk.java.net/jdk/jdk/rev/5e7cf99b1303 > > The original patch does not apply cleanly. There is not newThread(String > name, Runnable target) method in 8u, so discard this part of change. > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8190482-8u/webrev.00/ > > > Thanks, > > -Zhengyu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Oct 17 18:28:25 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 17 Oct 2021 19:28:25 +0100 Subject: (ch) InnocuousThread names In-Reply-To: References: <2B573F3A-49B4-48B5-B488-61748D216754@amazon.com> Message-ID: <3f70ecd4-a05e-1ec6-1266-c2dd0940d767@oracle.com> On 17/10/2021 04:24, Bernd Eckenfels wrote: > Looking at the code some more I wonder: > > * ?if defaultThreadFactoty should use a Thread group for the pool or > at least for NIO? > * If it can skip the security manager check and use InnocousThread > in all cases (to avoid ThreadLocals - not sure if some encode > cache is hurt by it?) > > * If it can skip the priveledged call as IThread does that itself. > Changing it to use InnocousThread unconditionally would likely change the performance profile as TLs would be cleared so I don't think we should change that. The SM is terminally deprecated and there will be cleaned required right across the JDK once it is eventually removed, it is possible that many usages of InnocousThread will no longer be needed. You may be right that it no longer needs the doPriv to create the InnocousThread, it looks like the code changed but some of the use-sites were not updated. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.java.net Mon Oct 18 07:39:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 18 Oct 2021 07:39:53 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v8] In-Reply-To: References: Message-ID: On Sat, 16 Oct 2021 08:37:09 GMT, Markus KARG wrote: >> Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. >> >> This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. >> >> *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Added code comments for private methods > > Signed-off-by: Markus Karg > - Added code comment for public method > > Signed-off-by: Markus Karg Still looks fine to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5421 From bpb at openjdk.java.net Mon Oct 18 17:03:49 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 18 Oct 2021 17:03:49 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v4] In-Reply-To: References: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> <5v_LSpUgg5nGalLhfC8e53sLkX0xlh39rE3FFsWnkYQ=.25b7ea6d-b5cb-485b-b7a6-a85f79b2be3a@github.com> Message-ID: On Sat, 16 Oct 2021 13:28:03 GMT, Markus KARG wrote: >>> The comments are much improved but inconsistent. For example some of them have `@param` and other javadoc tags and some do not. There is also some variation in detail level. >> >> Is it essential for *this* PR that *all* comments must be consistent? I understood @AlanBateman in a way that it is enough to simply *have some* and honestly, I did not find such high quality comments in all the existing code you showed me. Regarding the detail level, it even makes sense to only go into details *where needed* IMHO to not repeat the obvious. >> >>> On a process level, it would be better to wait for feedback on changes before integrating. This is especially so as a sponsor has to be comfortable with the content. Ideally at least one approval should be associated with the most recent commit. >> >> Understood. I thought that it is irrelevant when I ask for integration, as I already covered all open issues and @shipilev already marked this PR as reviewed *as-is* (*without* any comments at all). > >> On a process level, it would be better to wait for feedback on changes before integrating. This is especially so as a sponsor has to be comfortable with the content. Ideally at least one approval should be associated with the most recent commit. > > @bplb I don't want to make it wrong again, but I think this time I am right that I can integrate *right now* (even I pushed more comments requested by you), as you approved this PR *directly after* you requested that comments. If not, please directly tell me how to otherwise understand your approval. Thanks. @mkarg Yes you can go ahead and integrate. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From dholmes at openjdk.java.net Tue Oct 19 02:27:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 19 Oct 2021 02:27:48 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v6] In-Reply-To: References: Message-ID: On Sat, 16 Oct 2021 11:11:59 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/419 > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - * use `invokeWithArguments` to simplify new test > - Add test for liveness check with high-aririty downcalls > (make sure that if an exception occurs in a downcall because of liveness, > ref count of other resources are left intact). Hotspot changes seem fine. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From alanb at openjdk.java.net Tue Oct 19 06:56:52 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 19 Oct 2021 06:56:52 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel [v3] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 21:05:26 GMT, Brian Burkhalter wrote: >> Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 4619075: Add @since tags to new methods src/java.base/share/classes/java/nio/channels/Channels.java line 378: > 376: long totalBytesRead = 0L; > 377: int maxIndex = offset + length; > 378: for (int i = offset; i < maxIndex; i++) { There are a few problems with this loop. If the second/subsequent buffer is ready only then it will throw IllegalArgumentException after reading bytes into the first buffer. It also doesn't happen cases where there are I/O exceptions thrown after some bytes have been read. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From alanb at openjdk.java.net Tue Oct 19 07:03:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 19 Oct 2021 07:03:50 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel [v3] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 14:54:50 GMT, Brian Burkhalter wrote: > One other possibility I had thought of was to change `newChannel(InputStream)` and `newChannel(OutputStream)` to respectively return a `ScatteringByteChannel` and a `GatheringByteChannel` without changing the return types of the methods from their current declarations and instead calling out what is in fact returned in the javadoc. Yes, although might be a bit icky. Another possibility is to add a default method to ReadableByteChannel. I'm in two minds as to whether we need to do anything here as I haven't seen many cases where someone wants to do scattering read ops on channels backed by input streams. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From duke at openjdk.java.net Tue Oct 19 07:37:49 2021 From: duke at openjdk.java.net (Markus KARG) Date: Tue, 19 Oct 2021 07:37:49 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v4] In-Reply-To: References: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> <5v_LSpUgg5nGalLhfC8e53sLkX0xlh39rE3FFsWnkYQ=.25b7ea6d-b5cb-485b-b7a6-a85f79b2be3a@github.com> Message-ID: <_bgwplKC6Pd53GOBn1ilDbgcs6yBDZyBpcJeXl58q6I=.e9356eba-4c11-445f-89af-6c8369704c12@github.com> On Mon, 18 Oct 2021 17:01:02 GMT, Brian Burkhalter wrote: >Yes you can go ahead and integrate. Great, thanks a lot, Aleksey and Brian! :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From alanb at openjdk.java.net Tue Oct 19 11:05:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 19 Oct 2021 11:05:53 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v3] In-Reply-To: References: Message-ID: <26IW87mnFJ5-jloCAWIBSWpLtZFotwkqx28BgGm7mP0=.8668a835-452b-4168-b10d-3ea674bd65f6@github.com> On Thu, 23 Sep 2021 02:07:30 GMT, Brian Burkhalter wrote: >> Please consider this patch which would improve the performance of >> `FileChannel.transferTo()` on macOS and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274112: Modify transfer_read_write() not to throw if read or write fails src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 621: > 619: FileDescriptor targetFD = target.fd; > 620: if (targetFD == null) > 621: return IOStatus.UNSUPPORTED; How can the target have a null file descriptor? src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 762: > 760: // Attempt a transfer using native functions, if available > 761: if (target instanceof FileChannelImpl targetFCI) > 762: if ((n = transferToFileChannel(position, count, targetFCI)) >= 0) The check for whether the target channel is a FileChannelImpl is already in transferToDirectly so I assume that's the place that should be calling transferToFileChannel. src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1448: > 1446: // Transfers from src to dst, or returns IOStatus.UNSUPPORTED (-4) > 1447: // or IOStatus.UNSUPPORTED_CASE (-6) if kernel can't do that > 1448: private static native long transferToFileChannel0(FileDescriptor src, transferToFileChannel0 is static so we should probably change transferTo0 to keep the methods consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Wed Oct 20 00:21:09 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 20 Oct 2021 00:21:09 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v3] In-Reply-To: <26IW87mnFJ5-jloCAWIBSWpLtZFotwkqx28BgGm7mP0=.8668a835-452b-4168-b10d-3ea674bd65f6@github.com> References: <26IW87mnFJ5-jloCAWIBSWpLtZFotwkqx28BgGm7mP0=.8668a835-452b-4168-b10d-3ea674bd65f6@github.com> Message-ID: On Tue, 19 Oct 2021 11:02:56 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274112: Modify transfer_read_write() not to throw if read or write fails > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 621: > >> 619: FileDescriptor targetFD = target.fd; >> 620: if (targetFD == null) >> 621: return IOStatus.UNSUPPORTED; > > How can the target have a null file descriptor? It does not look like it can. I will remove that check. > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 762: > >> 760: // Attempt a transfer using native functions, if available >> 761: if (target instanceof FileChannelImpl targetFCI) >> 762: if ((n = transferToFileChannel(position, count, targetFCI)) >= 0) > > The check for whether the target channel is a FileChannelImpl is already in transferToDirectly so I assume that's the place that should be calling transferToFileChannel. I was looking at the file channel transfer as being a piece of logic at the same level as direct vs. trusted vs. arbitrary, not as a sub-case of direct. I think to change it as suggested would lead to some odd code: if (target instanceof FileChannelImpl fci) { if (!fileSupported) return transferToFileChannel(position, count, fci); targetFD = fci.fd; > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1448: > >> 1446: // Transfers from src to dst, or returns IOStatus.UNSUPPORTED (-4) >> 1447: // or IOStatus.UNSUPPORTED_CASE (-6) if kernel can't do that >> 1448: private static native long transferToFileChannel0(FileDescriptor src, > > transferToFileChannel0 is static so we should probably change transferTo0 to keep the methods consistent. Agreed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From mcimadamore at openjdk.java.net Wed Oct 20 11:14:19 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 20 Oct 2021 11:14:19 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v7] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/a4db81fe..52189683 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=05-06 Stats: 39 lines in 9 files changed: 1 ins; 10 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Wed Oct 20 14:00:30 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 20 Oct 2021 14:00:30 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v8] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix copyright header in TestArrayCopy ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/52189683..414952ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=06-07 Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From bpb at openjdk.java.net Wed Oct 20 16:40:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 20 Oct 2021 16:40:43 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel [v4] In-Reply-To: References: Message-ID: > Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4619075: Move read-only check to before read loop ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5922/files - new: https://git.openjdk.java.net/jdk/pull/5922/files/e06b2149..70cb65ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5922&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5922&range=02-03 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5922.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5922/head:pull/5922 PR: https://git.openjdk.java.net/jdk/pull/5922 From bpb at openjdk.java.net Wed Oct 20 16:40:45 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 20 Oct 2021 16:40:45 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel [v3] In-Reply-To: References: Message-ID: <3SpB1jBYq913zQ2w0upuTmrr8qYmgUTvuQSkZbWmq2Q=.4cd6992f-2026-4830-91b2-103a2faaf511@github.com> On Wed, 13 Oct 2021 21:05:26 GMT, Brian Burkhalter wrote: >> Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 4619075: Add @since tags to new methods I think I'd prefer to leave the proposed change as-is or withdraw it. I don't like returning something that requires relying on comments to interpret, and I like the default method idea even less. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From bpb at openjdk.java.net Wed Oct 20 16:40:49 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 20 Oct 2021 16:40:49 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel [v3] In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 06:53:50 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 4619075: Add @since tags to new methods > > src/java.base/share/classes/java/nio/channels/Channels.java line 378: > >> 376: long totalBytesRead = 0L; >> 377: int maxIndex = offset + length; >> 378: for (int i = offset; i < maxIndex; i++) { > > There are a few problems with this loop. If the second/subsequent buffer is read only then it will throw IllegalArgumentException after reading bytes into the first buffer. It also doesn't happen cases where there are I/O exceptions thrown after some bytes have been read. Read-only check is fixed. Not sure what to do about IOEs after bytes have been read. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From naoto at openjdk.java.net Wed Oct 20 17:32:22 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 20 Oct 2021 17:32:22 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value Message-ID: During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 ------------- Commit messages: - 8270490: Charset.forName() taking fallback default value Changes: https://git.openjdk.java.net/jdk/pull/6045/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270490 Stats: 117 lines in 3 files changed: 115 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6045/head:pull/6045 PR: https://git.openjdk.java.net/jdk/pull/6045 From alanb at openjdk.java.net Wed Oct 20 17:57:06 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 20 Oct 2021 17:57:06 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel [v3] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 16:35:18 GMT, Brian Burkhalter wrote: > Read-only check is fixed. Not sure what to do about IOEs after bytes have been read. It probably should return the bytes read and hope the I/O exception will be thrown when called again. I guess the question is whether this complexity is worth it. Maybe we need to think more about whether we really need this API. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From duke at openjdk.java.net Wed Oct 20 18:34:14 2021 From: duke at openjdk.java.net (Markus KARG) Date: Wed, 20 Oct 2021 18:34:14 GMT Subject: Integrated: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test In-Reply-To: References: Message-ID: <2-c7of5WX-6AY0o83OGZJlhdW8-fdFmrWOo4Ts5MYrI=.9d408fcc-441b-4261-8b59-da6703f23e2f@github.com> On Wed, 8 Sep 2021 17:17:32 GMT, Markus KARG wrote: > Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. > > This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. > > *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* This pull request has now been integrated. Changeset: 913f9281 Author: Markus Karg Committer: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/913f9281ada7ebb670ed93a088d28afeaa635eb7 Stats: 108 lines in 1 file changed: 48 ins; 34 del; 26 mod 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test Reviewed-by: shade, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From joehw at openjdk.java.net Wed Oct 20 18:40:05 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 20 Oct 2021 18:40:05 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 17:23:36 GMT, Naoto Sato wrote: > During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 Marked as reviewed by joehw (Reviewer). src/java.base/share/classes/java/nio/charset/Charset.java line 545: > 543: * @return A charset object for the named charset, or {@code fallback} > 544: * in case the charset object for the named charset is not > 545: * available. May be {@code null} A minor comment: it seems to me returning the fallback charset is sufficient, and "May be null" may be not necessary since the fallback charset is provided, it's expected if it's null. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Wed Oct 20 19:02:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 20 Oct 2021 19:02:30 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: Message-ID: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> > During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Moved the null sentence into @param tag. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6045/files - new: https://git.openjdk.java.net/jdk/pull/6045/files/a31dbdc7..4c2142be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6045/head:pull/6045 PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Wed Oct 20 19:02:31 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 20 Oct 2021 19:02:31 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 18:37:05 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the null sentence into @param tag. > > src/java.base/share/classes/java/nio/charset/Charset.java line 545: > >> 543: * @return A charset object for the named charset, or {@code fallback} >> 544: * in case the charset object for the named charset is not >> 545: * available. May be {@code null} > > A minor comment: it seems to me returning the fallback charset is sufficient, and "May be null" may be not necessary since the fallback charset is provided, it's expected if it's null. Thanks, Joe. Moved that explanation into the `fallback` param, which I initially intended. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From alanb at openjdk.java.net Wed Oct 20 19:02:31 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 20 Oct 2021 19:02:31 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 18:56:22 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/nio/charset/Charset.java line 545: >> >>> 543: * @return A charset object for the named charset, or {@code fallback} >>> 544: * in case the charset object for the named charset is not >>> 545: * available. May be {@code null} >> >> A minor comment: it seems to me returning the fallback charset is sufficient, and "May be null" may be not necessary since the fallback charset is provided, it's expected if it's null. > > Thanks, Joe. Moved that explanation into the `fallback` param, which I initially intended. The java.nio.charset package has the usual "Unless otherwise noted, passing a null argument ..." so if fallback is allowed to be null then you will need to add ", can null" to its description. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From joehw at openjdk.java.net Wed Oct 20 19:15:09 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 20 Oct 2021 19:15:09 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Wed Oct 20 19:15:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 20 Oct 2021 19:15:09 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 18:58:34 GMT, Alan Bateman wrote: >> Thanks, Joe. Moved that explanation into the `fallback` param, which I initially intended. > > The java.nio.charset package has the usual "Unless otherwise noted, passing a null argument ..." so if fallback is allowed to be null then you will need to add ", can null" to its description. Our comments crossed I guess? Moved the null allowance into `fallback`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From rriggs at openjdk.java.net Wed Oct 20 21:05:03 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 20 Oct 2021 21:05:03 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: <0SG8S4-aHXxYnbK9sq7IVi_sPcMsl_61iQTVxb2jYSA=.cbbd1868-bc04-45b5-83e1-6174a5091eed@github.com> On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. Looks good ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6045 From cverghese at openjdk.java.net Thu Oct 21 00:35:27 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 21 Oct 2021 00:35:27 GMT Subject: RFR: 8275536: [TEST] java.io.File and java.nio.File should return the same timestamp for lastModified Message-ID: The test validated that the precision returned by `java.io.File.lastModified` and `java.nio.file.Files.getLastModifiedTime` are the same. ------------- Commit messages: - 8275536: [TEST] java.io.File and java.nio.File should return the same timestamp for lastModified Changes: https://git.openjdk.java.net/jdk/pull/6054/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6054&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275536 Stats: 60 lines in 1 file changed: 60 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6054.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6054/head:pull/6054 PR: https://git.openjdk.java.net/jdk/pull/6054 From serb at openjdk.java.net Thu Oct 21 01:35:04 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 21 Oct 2021 01:35:04 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. src/java.base/share/classes/java/io/Console.java line 587: > 585: try { > 586: cs = Charset.forName(csname, null); > 587: } catch (Exception ignored) { } The comment which suggests this enhancement was about eliminating such "exception ignored" code paths. Is it still needed here? And if it is needed why do we pass the null as a fallback? src/java.base/share/classes/java/io/Console.java line 594: > 592: cs = Charset.forName(StaticProperty.nativeEncoding(), Charset.defaultCharset()); > 593: } catch (Exception ignored) { > 594: cs = Charset.defaultCharset(); What kind of actual improvements do we get here since the catch block is still in place? ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From bpb at openjdk.java.net Thu Oct 21 02:19:08 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 21 Oct 2021 02:19:08 GMT Subject: RFR: 8275536: [TEST] java.io.File and java.nio.File should return the same timestamp for lastModified In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 00:27:20 GMT, Clive Verghese wrote: > The test validated that the precision returned by `java.io.File.lastModified` and `java.nio.file.Files.getLastModifiedTime` are the same. test/jdk/java/nio/file/Files/LastModifiedTest.java line 43: > 41: public class LastModifiedTest { > 42: > 43: private final Instant milliPrecision = Instant.ofEpochMilli(1999L); This field could be `static final` and in which case named `MILLI_PRECISION`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6054 From bpb at openjdk.java.net Thu Oct 21 02:24:09 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 21 Oct 2021 02:24:09 GMT Subject: RFR: 8275536: [TEST] java.io.File and java.nio.File should return the same timestamp for lastModified In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 00:27:20 GMT, Clive Verghese wrote: > The test validated that the precision returned by `java.io.File.lastModified` and `java.nio.file.Files.getLastModifiedTime` are the same. test/jdk/java/nio/file/Files/LastModifiedTest.java line 46: > 44: > 45: @Test > 46: public void lastModified_ioAndNioAreAlwaysSame() throws IOException { Generally we don't use underscores in method names in favor of, e.g., `lastModifiedIoAndNioAreAlwaysSame` but that name seems awkward in either case. Maybe `verifyLastModifiedTime()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/6054 From cverghese at openjdk.java.net Thu Oct 21 05:27:37 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 21 Oct 2021 05:27:37 GMT Subject: RFR: 8275536: [TEST] java.io.File and java.nio.File should return the same timestamp for lastModified [v2] In-Reply-To: References: Message-ID: > The test validated that the precision returned by `java.io.File.lastModified` and `java.nio.file.Files.getLastModifiedTime` are the same. Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Update function and variable names ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6054/files - new: https://git.openjdk.java.net/jdk/pull/6054/files/a2a3f6e9..a0bb4a05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6054&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6054&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6054.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6054/head:pull/6054 PR: https://git.openjdk.java.net/jdk/pull/6054 From cverghese at openjdk.java.net Thu Oct 21 05:27:39 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 21 Oct 2021 05:27:39 GMT Subject: RFR: 8275536: [TEST] java.io.File and java.nio.File should return the same timestamp for lastModified In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 00:27:20 GMT, Clive Verghese wrote: > The test validated that the precision returned by `java.io.File.lastModified` and `java.nio.file.Files.getLastModifiedTime` are the same. @bplb Thank you for the feedback. I have addressed the comments and updated the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/6054 From alanb at openjdk.java.net Thu Oct 21 06:23:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Oct 2021 06:23:07 GMT Subject: RFR: 8275536: [TEST] java.io.File and java.nio.File should return the same timestamp for lastModified [v2] In-Reply-To: References: Message-ID: <_eWu8o7Km4okfVSi4HEdTh6hF_LiAdldQQBeQ8fTCWE=.94162ae5-2993-4f34-b0fb-d80c4b997224@github.com> On Thu, 21 Oct 2021 05:27:37 GMT, Clive Verghese wrote: >> The test validated that the precision returned by `java.io.File.lastModified` and `java.nio.file.Files.getLastModifiedTime` are the same. > > Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: > > Update function and variable names Can you add a bit more information here, or to the JBS issue, on this? Is this something to do with the glibc that Amazon are using? In general Files::getLastLastModified may return a FileTime of higher precision that the milliseconds returned by File::lastModified so maybe this test is to ensure that improves are ported to java.io.File too? At some point I expect we will re-implement File to layer over the newer implementation so File will benefit from improvements. I think test/jdk/java/io/File may be a better place for the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/6054 From alanb at openjdk.java.net Thu Oct 21 06:54:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Oct 2021 06:54:07 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Thu, 21 Oct 2021 01:30:05 GMT, Sergey Bylokhov wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the null sentence into @param tag. > > src/java.base/share/classes/java/io/Console.java line 587: > >> 585: try { >> 586: cs = Charset.forName(csname, null); >> 587: } catch (Exception ignored) { } > > The comment which suggests this enhancement was about eliminating such "exception ignored" code paths. Is it still needed here? And if it is needed why do we pass the null as a fallback? Right, I think both try-catch usages will be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From dfuchs at openjdk.java.net Thu Oct 21 09:37:13 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 21 Oct 2021 09:37:13 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: <2dVpiRSN-mhp69KZZ9jIUc7O1YiJ3CP5H1uRlEI7nMY=.3d5733d0-7d66-422d-8c21-01aea560f9cf@github.com> On Thu, 21 Oct 2021 06:50:41 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/io/Console.java line 587: >> >>> 585: try { >>> 586: cs = Charset.forName(csname, null); >>> 587: } catch (Exception ignored) { } >> >> The comment which suggests this enhancement was about eliminating such "exception ignored" code paths. Is it still needed here? And if it is needed why do we pass the null as a fallback? > > Right, I think both try-catch usages will be removed. Apparently `IllegalCharsetNameException` or `IllegalArgumentException` could still be thrown - so removing the `try-catch` would be a change of behaviour in those cases. It all depends on whether there is a chance that these exceptions could be thrown in this particular context (with these particular input parameters) - which I am not able to tell - but maybe someone more familiar with this code could... ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From rriggs at openjdk.java.net Thu Oct 21 15:03:09 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 21 Oct 2021 15:03:09 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Thu, 21 Oct 2021 01:31:31 GMT, Sergey Bylokhov wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the null sentence into @param tag. > > src/java.base/share/classes/java/io/Console.java line 594: > >> 592: cs = Charset.forName(StaticProperty.nativeEncoding(), Charset.defaultCharset()); >> 593: } catch (Exception ignored) { >> 594: cs = Charset.defaultCharset(); > > What kind of actual improvements do we get here since the catch block is still in place? In the case of Console, both charset names come from system properties and could refer to invalid or unavailable charsets. (null is handled separately). The code silently ignores the invalid values. The new method , as is, is not a fully satisfying replacement. Catching Exception is too broad a catch but may be warranted in this case so that some Console charset is selected. The new method would be useful in more cases if the default was returned for any of IllegalCharsetNameException, IllegalArgumentException, and UnsupportedCharsetException. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From mcimadamore at openjdk.java.net Thu Oct 21 15:20:16 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 21 Oct 2021 15:20:16 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v9] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - Fix regression in VaList treatment on AArch64 (contributed by @nick-arm) - Merge branch 'master' into JEP-419 - Fix copyright header in TestArrayCopy - Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!) - * use `invokeWithArguments` to simplify new test - Add test for liveness check with high-aririty downcalls (make sure that if an exception occurs in a downcall because of liveness, ref count of other resources are left intact). - * Fix javadoc issue in VaList * Fix bug in concurrent logic for shared scope acquire - Address review comments - Apply suggestions from code review Co-authored-by: Paul Sandoz - Fix TestLinkToNativeRBP test - ... and 5 more: https://git.openjdk.java.net/jdk/compare/aeabb3df...5c69eabf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/414952ad..5c69eabf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=07-08 Stats: 25202 lines in 587 files changed: 18962 ins; 4240 del; 2000 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From naoto at openjdk.java.net Thu Oct 21 16:06:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 21 Oct 2021 16:06:07 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <2dVpiRSN-mhp69KZZ9jIUc7O1YiJ3CP5H1uRlEI7nMY=.3d5733d0-7d66-422d-8c21-01aea560f9cf@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> <2dVpiRSN-mhp69KZZ9jIUc7O1YiJ3CP5H1uRlEI7nMY=.3d5733d0-7d66-422d-8c21-01aea560f9cf@github.com> Message-ID: On Thu, 21 Oct 2021 09:33:30 GMT, Daniel Fuchs wrote: >> Right, I think both try-catch usages will be removed. > > Apparently `IllegalCharsetNameException` or `IllegalArgumentException` could still be thrown - so removing the `try-catch` would be a change of behaviour in those cases. It all depends on whether there is a chance that these exceptions could be thrown in this particular context (with these particular input parameters) - which I am not able to tell - but maybe someone more familiar with this code could... I first thought of swallowing all exceptions in 2-arg forName(), but decided not to do that. Because `IllegalArgumentException` and `IllegalCharsetNameException` are for the validity of the passed `charsetName`, like detecting `null` or invalid chars like "??". On the other hand, `UnsupportedCharsetException` is for the availability which varies depending on the user's settings and or platform, which can be safely replaced with `fallback` charset. So yes, it is not totally getting rid of `try-catch` but it avoids `UnsupportedCharsetException` which is only detectable at runtime. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Thu Oct 21 16:06:08 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 21 Oct 2021 16:06:08 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Thu, 21 Oct 2021 15:00:03 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/io/Console.java line 594: >> >>> 592: cs = Charset.forName(StaticProperty.nativeEncoding(), Charset.defaultCharset()); >>> 593: } catch (Exception ignored) { >>> 594: cs = Charset.defaultCharset(); >> >> What kind of actual improvements do we get here since the catch block is still in place? > > In the case of Console, both charset names come from system properties and could refer to invalid or unavailable charsets. (null is handled separately). The code silently ignores the invalid values. The new method , as is, is not a fully satisfying replacement. Catching Exception is too broad a catch but may be warranted in this case so that some Console charset is selected. > > The new method would be useful in more cases if the default was returned for any of > IllegalCharsetNameException, IllegalArgumentException, and UnsupportedCharsetException. Since we do support all the encodings for platforms we support out-of-the-box, it could still be possible that the user can specify his/her console encoding to the one we do not support. In that case, we can safely use the default `UTF-8` without throwing/catching `UnsupportedCharsetException`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From itakiguchi at openjdk.java.net Thu Oct 21 16:09:04 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 21 Oct 2021 16:09:04 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: <3U2qAPXYrhhhfg8dF80__Gam5t7qXQWmJWcAOhTqAZE=.f0be7879-0180-4e6e-ad5d-837751536e77@github.com> On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. I'm not reviewer. I'd like to write down following code without `try-catch`. var cs = Charset.forName(charsetName, null); if (cs == null) cs = StandardCharsets.UTF_8; or please find out more easy way. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Thu Oct 21 18:04:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 21 Oct 2021 18:04:07 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <3U2qAPXYrhhhfg8dF80__Gam5t7qXQWmJWcAOhTqAZE=.f0be7879-0180-4e6e-ad5d-837751536e77@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> <3U2qAPXYrhhhfg8dF80__Gam5t7qXQWmJWcAOhTqAZE=.f0be7879-0180-4e6e-ad5d-837751536e77@github.com> Message-ID: On Thu, 21 Oct 2021 16:06:31 GMT, Ichiroh Takiguchi wrote: > I'd like to write down following code without `try-catch`. You don't *have to* try-catch those exceptions if you are not interested, as they are subclasses of `RuntimeException`. > ``` > var cs = Charset.forName(charsetName, null); > if (cs == null) cs = StandardCharsets.UTF_8; > ``` This could be simplified to var cs = Charset.forName(charsetName, StandardCharsets.UTF_8); ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From bpb at openjdk.java.net Thu Oct 21 21:40:06 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 21 Oct 2021 21:40:06 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v3] In-Reply-To: References: Message-ID: <8ik0aKwFgv4ltDFVGqHFWSZqcW_ZeaCWp9zjjyTVbWM=.61b471ce-ac80-4dd0-a264-739b31346aba@github.com> On Wed, 22 Sep 2021 13:25:56 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273922: Make join() reject absolute path in 1nth in 'name' parameter > > src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java line 64: > >> 62: String path = join(file.getPathForWin32Calls(), name); >> 63: WindowsPath wp = WindowsPath.createFromNormalizedPath(wfs, path); >> 64: return wp.getPathForWin32Calls(); > > I think we can simplify this to avoid most of the conversions, I'll get back to you soon with a proposal for this. Do you have any further suggestions on this? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From cverghese at openjdk.java.net Thu Oct 21 22:54:34 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 21 Oct 2021 22:54:34 GMT Subject: RFR: 8275536: [TEST] java.io.File and java.nio.File should return the same timestamp for lastModified [v3] In-Reply-To: References: Message-ID: > The test validated that the precision returned by `java.io.File.lastModified` and `java.nio.file.Files.getLastModifiedTime` are the same. Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: Move test from java/nio to java/io ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6054/files - new: https://git.openjdk.java.net/jdk/pull/6054/files/a0bb4a05..d9531017 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6054&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6054&range=01-02 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6054.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6054/head:pull/6054 PR: https://git.openjdk.java.net/jdk/pull/6054 From cverghese at openjdk.java.net Thu Oct 21 22:54:36 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Thu, 21 Oct 2021 22:54:36 GMT Subject: RFR: 8275536: [TEST] java.io.File and java.nio.File should return the same timestamp for lastModified [v2] In-Reply-To: <_eWu8o7Km4okfVSi4HEdTh6hF_LiAdldQQBeQ8fTCWE=.94162ae5-2993-4f34-b0fb-d80c4b997224@github.com> References: <_eWu8o7Km4okfVSi4HEdTh6hF_LiAdldQQBeQ8fTCWE=.94162ae5-2993-4f34-b0fb-d80c4b997224@github.com> Message-ID: On Thu, 21 Oct 2021 06:20:31 GMT, Alan Bateman wrote: >> Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: >> >> Update function and variable names > > Can you add a bit more information here, or to the JBS issue, on this? Is this something to do with the glibc that Amazon are using? > > In general Files::getLastLastModified may return a FileTime of higher precision that the milliseconds returned by File::lastModified so maybe this test is to ensure that improvements are ported to java.io.File too? At some point I expect we will re-implement File to layer over the newer implementation so File will benefit from improvements. > > I think test/jdk/java/io/File may be a better place for the test. Hi @AlanBateman, Thank you for the feedback, I have moved the test to `tets/jdk/java/io/File` and add some more information regarding this. Yes, The test is to ensure that improvements to one are ported to both implementations. ------------- PR: https://git.openjdk.java.net/jdk/pull/6054 From itakiguchi at openjdk.java.net Fri Oct 22 00:29:03 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Fri, 22 Oct 2021 00:29:03 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> <3U2qAPXYrhhhfg8dF80__Gam5t7qXQWmJWcAOhTqAZE=.f0be7879-0180-4e6e-ad5d-837751536e77@github.com> Message-ID: On Thu, 21 Oct 2021 18:00:46 GMT, Naoto Sato wrote: >> I'm not reviewer. >> >> I'd like to write down following code without `try-catch`. >> >> var cs = Charset.forName(charsetName, null); >> if (cs == null) cs = StandardCharsets.UTF_8; >> >> or please find out more easy way. > >> I'd like to write down following code without `try-catch`. > > You don't *have to* try-catch those exceptions if you are not interested, as they are subclasses of `RuntimeException`. > >> ``` >> var cs = Charset.forName(charsetName, null); >> if (cs == null) cs = StandardCharsets.UTF_8; >> ``` > > This could be simplified to > > > var cs = Charset.forName(charsetName, StandardCharsets.UTF_8); @naotoj Oh sorry, I'd like to detect fallback charset is used, like: var cs = Charset.forName(charsetName, null); if (cs == null) { System.err.println("Used UTF-8 encoding instead of "+charsetName+"); cs = StandardCharsets.UTF_8; } ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From serb at openjdk.java.net Fri Oct 22 02:11:01 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 22 Oct 2021 02:11:01 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> <2dVpiRSN-mhp69KZZ9jIUc7O1YiJ3CP5H1uRlEI7nMY=.3d5733d0-7d66-422d-8c21-01aea560f9cf@github.com> Message-ID: On Thu, 21 Oct 2021 16:03:29 GMT, Naoto Sato wrote: >> Apparently `IllegalCharsetNameException` or `IllegalArgumentException` could still be thrown - so removing the `try-catch` would be a change of behaviour in those cases. It all depends on whether there is a chance that these exceptions could be thrown in this particular context (with these particular input parameters) - which I am not able to tell - but maybe someone more familiar with this code could... > > I first thought of swallowing all exceptions in 2-arg forName(), but decided not to do that. Because `IllegalArgumentException` and `IllegalCharsetNameException` are for the validity of the passed `charsetName`, like detecting `null` or invalid chars like "??". On the other hand, `UnsupportedCharsetException` is for the availability which varies depending on the user's settings and or platform, which can be safely replaced with `fallback` charset. So yes, it is not totally getting rid of `try-catch` but it avoids `UnsupportedCharsetException` which is only detectable at runtime. Then what is the benefit, if the user will have to write such code anyway?: try { cs = Charset.forName(StaticProperty.nativeEncoding(), fallback); } catch (Exception ignored) { cs = fallback; } Even in the current code update it can work well w/o the second parameter. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From duke at openjdk.java.net Fri Oct 22 03:38:03 2021 From: duke at openjdk.java.net (Glavo) Date: Fri, 22 Oct 2021 03:38:03 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. I'm not reviewer. I think maybe we should check all the usage of `Charset.isSupported`. At present, `Charset.isSupported` and `Charset.forName` are often used continuously, such as in `StringCoding`: class StringCoding { // ... private static Charset lookupCharset(String csn) { if (Charset.isSupported(csn)) { try { return Charset.forName(csn); } catch (UnsupportedCharsetException x) { throw new Error(x); } } return null; } //... } This calls `Charset.lookup` twice. Replacing it with such code should eliminate unnecessary lookup: private static Charset lookupCharset(String csn) { return Charset.forName(csn, null); } ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From duke at openjdk.java.net Fri Oct 22 04:57:12 2021 From: duke at openjdk.java.net (Glavo) Date: Fri, 22 Oct 2021 04:57:12 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Moved the null sentence into @param tag. Oh, I found that I checked the outdated source code. Now this problem does not exist in `StringCoding`. I simply browsed the latest source code of JDK and found that this idiom no longer appears outside jline. I believe that the source code of jline does not need to be modified in openjdk. But I noticed `LauncherHelper.makePlatformString` (https://github.com/openjdk/jdk/blob/c978ca87de2d9152345dfd85983278c42bb28cd3/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L887) I don't understand why it stores `encoding` string and `isCharsetSupported` boolean values. Nor do I find references to these two fields in native code. I think it can benefit from the improvement in this PR like this? private static final String encprop = "sun.jnu.encoding"; private static Charset charset = null; /* * converts a c or a byte array to a platform specific string, * previously implemented as a native method in the launcher. */ static String makePlatformString(boolean printToStderr, byte[] inArray) { initOutput(printToStderr); if (charset == null) { charset = Charset.forName(encprop, Charset.defaultCharset()); } return new String(inArray, charset); } ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Fri Oct 22 17:33:43 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 22 Oct 2021 17:33:43 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: References: Message-ID: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> > During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed `@throws IllegalCharsetNameException` ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6045/files - new: https://git.openjdk.java.net/jdk/pull/6045/files/4c2142be..7c73c5ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=01-02 Stats: 32 lines in 3 files changed: 6 ins; 22 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6045/head:pull/6045 PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Fri Oct 22 17:38:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 22 Oct 2021 17:38:07 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> Message-ID: On Fri, 22 Oct 2021 04:54:35 GMT, Glavo wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the null sentence into @param tag. > > Oh, I found that I checked the outdated source code. Now this problem does not exist in `StringCoding`. > > I simply browsed the latest source code of JDK and found that this idiom no longer appears outside jline. I believe that the source code of jline does not need to be modified in openjdk. > > But I noticed `LauncherHelper.makePlatformString` (https://github.com/openjdk/jdk/blob/c978ca87de2d9152345dfd85983278c42bb28cd3/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L887) > > I don't understand why it stores `encoding` string and `isCharsetSupported` boolean values. Nor do I find references to these two fields in native code. I think it may be improved in this PR like this: > > > > private static final String encprop = "sun.jnu.encoding"; > private static Charset charset = null; > > /* > * converts a c or a byte array to a platform specific string, > * previously implemented as a native method in the launcher. > */ > static String makePlatformString(boolean printToStderr, byte[] inArray) { > initOutput(printToStderr); > if (charset == null) { > charset = Charset.forName(System.getProperty(encprop), Charset.defaultCharset()); > } > return new String(inArray, charset); > } @Glavo, thank you for the suggestions. Although applying the new method in the JDK code would be useful, I'd keep this PR just to introduce this new method. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Fri Oct 22 17:38:08 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 22 Oct 2021 17:38:08 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v2] In-Reply-To: References: <9673dBKTx-9BLrJfErLJe1X_0K6yCCCusPhY4LdgoPI=.d0b1df23-bd53-4bae-b972-aec328a41fb5@github.com> <2dVpiRSN-mhp69KZZ9jIUc7O1YiJ3CP5H1uRlEI7nMY=.3d5733d0-7d66-422d-8c21-01aea560f9cf@github.com> Message-ID: On Fri, 22 Oct 2021 02:07:44 GMT, Sergey Bylokhov wrote: >> I first thought of swallowing all exceptions in 2-arg forName(), but decided not to do that. Because `IllegalArgumentException` and `IllegalCharsetNameException` are for the validity of the passed `charsetName`, like detecting `null` or invalid chars like "??". On the other hand, `UnsupportedCharsetException` is for the availability which varies depending on the user's settings and or platform, which can be safely replaced with `fallback` charset. So yes, it is not totally getting rid of `try-catch` but it avoids `UnsupportedCharsetException` which is only detectable at runtime. > > Then what is the benefit, if the user will have to write such code anyway?: > > try { > cs = Charset.forName(StaticProperty.nativeEncoding(), fallback); > } catch (Exception ignored) { > cs = fallback; > } > > Even in the current code update it can work well w/o the second parameter. OK, I revised the API to swallow `IllegalCharsetNameException`. This will effectively remove try-catch clauses, as `IllegalArgumentException` is considered an error, and simply avoided by a null check. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From rriggs at openjdk.java.net Fri Oct 22 20:06:08 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 22 Oct 2021 20:06:08 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed `@throws IllegalCharsetNameException` Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From serb at openjdk.java.net Sat Oct 23 01:46:07 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 23 Oct 2021 01:46:07 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed `@throws IllegalCharsetNameException` src/java.base/share/classes/java/io/Console.java line 589: > 587: } > 588: if (cs == null) { > 589: cs = Charset.forName(StaticProperty.nativeEncoding(), Charset.defaultCharset()); Not sure but looks like this class tries to maintain 80 chars per line rule? ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From itakiguchi at openjdk.java.net Sat Oct 23 03:19:06 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Sat, 23 Oct 2021 03:19:06 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: <7GKyMwKrVn66eA1mqrp_OVlLh6G0hwAIfdiJToM6S78=.0fcdd0c8-09da-4c32-8eb6-bd6181ae5d71@github.com> On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed `@throws IllegalCharsetNameException` About javadoc, I think following description is not clear. * @param fallback * fallback charset in case the charset object for the named * charset is not available. May be {@code null} ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From alanb at openjdk.java.net Sat Oct 23 06:46:04 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 23 Oct 2021 06:46:04 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed `@throws IllegalCharsetNameException` I think you'll need to adjust the description make it clear that "fallback" is used when the input is not a legal charset name or the charset is not available. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From duke at openjdk.java.net Sat Oct 23 14:03:11 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Sat, 23 Oct 2021 14:03:11 GMT Subject: RFR: 8264762: ByteBuffer.byteOrder(BIG_ENDIAN).asXBuffer.put(Xarray) and ByteBuffer.byteOrder(nativeOrder()).asXBuffer.put(Xarray) are slow [v3] In-Reply-To: References: <_IpcmMVZxGDatnYm_y5zoKDhVt_ptQRmmulgJF63vGw=.cd2fc3f0-a7de-438e-854f-20c60c3079c1@github.com> Message-ID: On Tue, 27 Apr 2021 19:00:58 GMT, Brian Burkhalter wrote: >> Please consider this request to accelerate absolute and relative bulk array transfer on views of heap byte buffers where the element size is greater than one. What currently happens is that the transfer devolves to a ?loopy? element-by-element copy such as >> >> int end = offset + length; >> for (int i = offset, j = index; i < end; i++, j++) >> dst[i] = get(j); >> >> for `get()`, and >> >> int end = offset + length; >> for (int i = offset, j = index; i < end; i++, j++) >> this.put(j, src[i]); >> >> for `put()`. This is of course relatively slow. >> >> The change proposed hoists the accelerated versions of these methods using the `ScopedMemoryAccess` methods `copyMemory()` and `copySwapMemory()` from `Direct-X-Buffer` to `X-Buffer`. The array bulk transfer methods are removed from `Direct-X-Buffer` itself. The number of lines of code in the templates decreases by 87. >> >> With this change the throughput of array bulk `put()` and `get()` for heap view buffers is increased by a factor of 6 to 11 compared with the current code. The performance of direct view buffers does not appear to be affected. >> >> No tests are modified or added as existing tests already cover these methods. All tests in CI tiers 1-3 passed on all platforms. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8264762: Remove dead code at X-Buffer:799 src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 395: > 393: Objects.checkFromIndexSize(offset, length, dst.length); > 394: > 395: long dstOffset = ARRAY_BASE_OFFSET + ((long)offset << $LG_BYTES_PER_VALUE$); It seems that `DirectByteBuffer.ARRAY_BASE_OFFSET` is now unused and can be removed from `Direct-X-Buffer.java.template` ------------- PR: https://git.openjdk.java.net/jdk/pull/3660 From duke at openjdk.java.net Sat Oct 23 16:01:20 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 23 Oct 2021 16:01:20 GMT Subject: RFR: 8275840: Testing FileChannel.transferTo(FileChannel) with more than 2 GB of data Message-ID: Testing `FileChannel.transferTo(FileChannel)` with more than 2 GB of data is covering the case that *multiple* iterations of `FileChannel.transferTo(FileChannel)` are actually performed by the test. This change was requested Alan Bateman @AlanBateman. ------------- Commit messages: - Testing FileChannel.transferTo(FileChannel) with more than 2 GB of data Changes: https://git.openjdk.java.net/jdk/pull/6093/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6093&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275840 Stats: 28 lines in 1 file changed: 28 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6093.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6093/head:pull/6093 PR: https://git.openjdk.java.net/jdk/pull/6093 From serb at openjdk.java.net Sat Oct 23 19:32:01 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 23 Oct 2021 19:32:01 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed `@throws IllegalCharsetNameException` Just an idea, should we check that the second parameter is null or not? Any pros and cons of that? For example should this code be allowed: var cs = Charset.forName(charsetName, null); if (cs == null) { System.err.println("Used UTF-8 encoding instead of "+charsetName+"); cs = StandardCharsets.UTF_8; } Or something like this should be forced: var cs = Charset.forName(charsetName, fallback); if (cs == fallback) { System.err.println("Used UTF-8 encoding instead of "+charsetName+"); } I have no preference. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Sat Oct 23 22:13:35 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 23 Oct 2021 22:13:35 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: > During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflecting review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6045/files - new: https://git.openjdk.java.net/jdk/pull/6045/files/7c73c5ba..0e787e7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6045&range=02-03 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6045/head:pull/6045 PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Sat Oct 23 22:13:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 23 Oct 2021 22:13:37 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Sat, 23 Oct 2021 06:42:52 GMT, Alan Bateman wrote: > I think you'll need to adjust the description make it clear that "fallback" is used when the input is not a legal charset name or the charset is not available. Made the method description clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Sat Oct 23 22:13:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 23 Oct 2021 22:13:41 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v3] In-Reply-To: References: <7IjiRqEGugX1DiruWOX9zP7nh9b7zUc0EwCOMGpNspE=.e5c488da-e4b3-42bf-852e-e45506906fa0@github.com> Message-ID: On Sat, 23 Oct 2021 19:29:30 GMT, Sergey Bylokhov wrote: > Just an idea, should we check that the second parameter is null or not? Any pros and cons of that? For example should this code be allowed: > > ``` > var cs = Charset.forName(charsetName, null); > if (cs == null) { > System.err.println("Used UTF-8 encoding instead of "+charsetName+"); > cs = StandardCharsets.UTF_8; > } > ``` Yes, that's the whole purpose of allowing `null` for `fallback`. > src/java.base/share/classes/java/io/Console.java line 589: > >> 587: } >> 588: if (cs == null) { >> 589: cs = Charset.forName(StaticProperty.nativeEncoding(), Charset.defaultCharset()); > > Not sure but looks like this class tries to maintain 80 chars per line rule? Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From alanb at openjdk.java.net Sun Oct 24 06:41:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 24 Oct 2021 06:41:07 GMT Subject: RFR: 8275536: Add test to check that File::lastModified returns same time stamp as Files.getLastModifiedTime [v3] In-Reply-To: References: Message-ID: <0l7h9ZX6iAMh6jCauvOu8uGJKhoR_1HmDMhXVd3gIp4=.c258eaa9-de72-4bbb-95aa-23fae83759c5@github.com> On Thu, 21 Oct 2021 22:54:34 GMT, Clive Verghese wrote: >> The test validated that the precision returned by `java.io.File.lastModified` and `java.nio.file.Files.getLastModifiedTime` are the same. > > Clive Verghese has updated the pull request incrementally with one additional commit since the last revision: > > Move test from java/nio to java/io Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6054 From alanb at openjdk.java.net Sun Oct 24 06:59:05 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 24 Oct 2021 06:59:05 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v3] In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 02:07:30 GMT, Brian Burkhalter wrote: >> Please consider this patch which would improve the performance of >> `FileChannel.transferTo()` on macOS and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274112: Modify transfer_read_write() not to throw if read or write fails Are you planning to update the PR with the changes that we discussed here? ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From redestad at openjdk.java.net Mon Oct 25 11:31:14 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 25 Oct 2021 11:31:14 GMT Subject: RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings Message-ID: Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: Before: Benchmark (size) (type) Mode Cnt Score Error Units CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op Patched: Benchmark (size) (type) Mode Cnt Score Error Units CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. Testing: tier1-3 ------------- Commit messages: - Use field directly - Grant accessClassInPackage.jdk.internal.access permission to jdk.charsets module - 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings Changes: https://git.openjdk.java.net/jdk/pull/6102/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6102&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275863 Stats: 35 lines in 5 files changed: 24 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6102/head:pull/6102 PR: https://git.openjdk.java.net/jdk/pull/6102 From rriggs at openjdk.java.net Mon Oct 25 14:16:09 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 25 Oct 2021 14:16:09 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: <8S6MNJSIX_s2OXqoy2rD0ty4kyjxuVZ4wG_6W0qFtOw=.97aafb88-bbcf-4f18-8729-bbbd5c066d08@github.com> On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From duke at openjdk.java.net Mon Oct 25 15:38:07 2021 From: duke at openjdk.java.net (Mike Hearn) Date: Mon, 25 Oct 2021 15:38:07 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v3] In-Reply-To: References: Message-ID: <6x0j-I5O0vdljDO2DIp3fNMc3StFKzgPjM_j5dv1Z9g=.d1d35038-fe62-4778-ae4f-70951cfa53ae@github.com> On Tue, 21 Sep 2021 19:28:58 GMT, Brian Burkhalter wrote: >> Modify `sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsPath,String)` to handle file names which exceed the limit. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8273922: Make join() reject absolute path in 1nth in 'name' parameter Thanks for fixing this Brian. I made my own attempt at a fix (I reported the bug originally) and came up with a different approach which simply removes the attempt to use short paths when possible, and always uses "long mode" paths. It passes tier1 and as far as I can tell should always work. diff --git a/src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java b/src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java index 54ecaf152c1..11c0e6b929c 100644 --- a/src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java +++ b/src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java @@ -228,7 +228,7 @@ class WindowsFileCopy { String linkTarget = WindowsLinkSupport.readLink(source); int flags = SYMBOLIC_LINK_FLAG_DIRECTORY; CreateSymbolicLink(targetPath, - WindowsPath.addPrefixIfNeeded(linkTarget), + WindowsPath.addLongPathPrefix(linkTarget), flags); } } catch (WindowsException x) { @@ -431,7 +431,7 @@ class WindowsFileCopy { } else { String linkTarget = WindowsLinkSupport.readLink(source); CreateSymbolicLink(targetPath, - WindowsPath.addPrefixIfNeeded(linkTarget), + WindowsPath.addLongPathPrefix(linkTarget), SYMBOLIC_LINK_FLAG_DIRECTORY); } } catch (WindowsException x) { diff --git a/src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java b/src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java index 84658566873..e83e47505ba 100644 --- a/src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java +++ b/src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java @@ -589,7 +589,7 @@ class WindowsFileSystemProvider // create the link try { CreateSymbolicLink(link.getPathForWin32Calls(), - WindowsPath.addPrefixIfNeeded(target.toString()), + WindowsPath.addLongPathPrefix(target.toString()), flags); } catch (WindowsException x) { if (x.lastError() == ERROR_INVALID_REPARSE_DATA) { diff --git a/src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java b/src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java index 864663a1738..4bcd8a75222 100644 --- a/src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java +++ b/src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java @@ -230,7 +230,7 @@ class WindowsLinkSupport { int end = (next == -1) ? path.length() : next; String search = sb.toString() + path.substring(curr, end); try { - FirstFile fileData = FindFirstFile(WindowsPath.addPrefixIfNeeded(search)); + FirstFile fileData = FindFirstFile(WindowsPath.addLongPathPrefix(search)); FindClose(fileData.handle()); // if a reparse point is encountered then we must return the diff --git a/src/java.base/windows/classes/sun/nio/fs/WindowsPath.java b/src/java.base/windows/classes/sun/nio/fs/WindowsPath.java index 8500646a96f..b93b31368b5 100644 --- a/src/java.base/windows/classes/sun/nio/fs/WindowsPath.java +++ b/src/java.base/windows/classes/sun/nio/fs/WindowsPath.java @@ -172,12 +172,8 @@ class WindowsPath implements Path { } // use this path for Win32 calls - // This method will prefix long paths with \?\ or \?\UNC as required. + // This method will prefix paths with \?\ or \?\UNC in order to enable long path mode. String getPathForWin32Calls() throws WindowsException { - // short absolute paths can be used directly - if (isAbsolute() && path.length() <= MAX_PATH) - return path; - // return cached values if available WeakReference ref = pathForWin32Calls; String resolved = (ref != null) ? ref.get() : null; @@ -189,18 +185,18 @@ class WindowsPath implements Path { // resolve against default directory resolved = getAbsolutePath(); - // Long paths need to have "." and ".." removed and be prefixed with - // "\?". Note that it is okay to remove ".." even when it follows + // Paths need to have "." and ".." removed and be prefixed with + // "\?", as otherwise paths can be at most 247 characters long. + // + // Note that it is okay to remove ".." even when it follows // a link - for example, it is okay for foo/link/../bar to be changed // to foo/bar. The reason is that Win32 APIs to access foo/link/../bar // will access foo/bar anyway (which differs to Unix systems) - if (resolved.length() > MAX_PATH) { - if (resolved.length() > MAX_LONG_PATH) { - throw new WindowsException("Cannot access file with path exceeding " - + MAX_LONG_PATH + " characters"); - } - resolved = addPrefixIfNeeded(GetFullPathName(resolved)); + if (resolved.length() > MAX_LONG_PATH) { + throw new WindowsException("Cannot access file with path exceeding " + + MAX_LONG_PATH + " characters"); } + resolved = addLongPathPrefix(GetFullPathName(resolved)); // cache the resolved path (except drive relative paths as the working // directory on removal media devices can change during the lifetime @@ -279,16 +275,13 @@ class WindowsPath implements Path { Character.toUpperCase(root2.charAt(0)); } - // Add long path prefix to path if required - static String addPrefixIfNeeded(String path) { - if (path.length() > MAX_PATH) { - if (path.startsWith("\\\")) { - path = "\\\?\\UNC" + path.substring(1, path.length()); - } else { - path = "\\\?\" + path; - } + // Add long path prefix to path. + static String addLongPathPrefix(String path) { + if (path.startsWith("\\\")) { + return "\\\?\\UNC" + path.substring(1, path.length()); + } else { + return "\\\?\" + path; } - return path; } @Override ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From alanb at openjdk.java.net Mon Oct 25 15:43:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 25 Oct 2021 15:43:07 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v3] In-Reply-To: <6x0j-I5O0vdljDO2DIp3fNMc3StFKzgPjM_j5dv1Z9g=.d1d35038-fe62-4778-ae4f-70951cfa53ae@github.com> References: <6x0j-I5O0vdljDO2DIp3fNMc3StFKzgPjM_j5dv1Z9g=.d1d35038-fe62-4778-ae4f-70951cfa53ae@github.com> Message-ID: <2KWO2orgj5AFlj9Sqr0GW-0Bb52DpT615jNuVqaH7Iw=.986890b2-32f0-4c06-a1ff-23b2aa2b8c63@github.com> On Mon, 25 Oct 2021 15:35:06 GMT, Mike Hearn wrote: > Thanks for fixing this Brian. I made my own attempt at a fix (I reported the bug originally) and came up with a different approach which simply removes the attempt to use short paths when possible, and always uses "long mode" paths. It passes tier1 and as far as I can tell should always work. No, we always try to use short paths if possible to avoid needing to convert to absolute paths. So I think your approach is a bit outside the scope of this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From duke at openjdk.java.net Mon Oct 25 15:50:06 2021 From: duke at openjdk.java.net (Mike Hearn) Date: Mon, 25 Oct 2021 15:50:06 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v3] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 19:28:58 GMT, Brian Burkhalter wrote: >> Modify `sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsPath,String)` to handle file names which exceed the limit. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8273922: Make join() reject absolute path in 1nth in 'name' parameter Ah, OK. Is converting to an absolute path unexpectedly expensive on Windows, or there's some other downside? I couldn't figure out the rationale from the code originally, so it'd be good to add in a comment explaining why an effort is made to use short form when possible. Otherwise someone else might spot the same 'simplification' in future. ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From naoto at openjdk.java.net Mon Oct 25 16:18:17 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 25 Oct 2021 16:18:17 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets Message-ID: Trivial clean-up. ------------- Commit messages: - 8275767: JDK source code contains redundant boolean operations in jdk.charsets Changes: https://git.openjdk.java.net/jdk/pull/6110/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6110&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275767 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6110/head:pull/6110 PR: https://git.openjdk.java.net/jdk/pull/6110 From joehw at openjdk.java.net Mon Oct 25 16:29:05 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 25 Oct 2021 16:29:05 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From lancea at openjdk.java.net Mon Oct 25 16:39:03 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 25 Oct 2021 16:39:03 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6110 From bpb at openjdk.java.net Mon Oct 25 16:57:41 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 25 Oct 2021 16:57:41 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v4] In-Reply-To: References: Message-ID: <1AR4tgaz1JdXutbQMh7FNoG0SHk1nHznl5H9n2Jzk3U=.545d612d-8eee-4290-8571-e5a9e18fe680@github.com> > Please consider this patch which would improve the performance of > `FileChannel.transferTo()` on macOS and Windows. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274112: Make transferTo0() static; remove check for null FileDescriptor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5623/files - new: https://git.openjdk.java.net/jdk/pull/5623/files/6ad473da..001ffa2f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5623&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5623&range=02-03 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5623.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5623/head:pull/5623 PR: https://git.openjdk.java.net/jdk/pull/5623 From rriggs at openjdk.java.net Mon Oct 25 17:01:03 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 25 Oct 2021 17:01:03 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. Given that the code has been that way for a *long time*, did you check that both paths work as intended and that tests exist for both paths? ------------- PR: https://git.openjdk.java.net/jdk/pull/6110 From naoto at openjdk.java.net Mon Oct 25 17:19:11 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 25 Oct 2021 17:19:11 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. No, I did not check. I simply removed the `true &&` as it is logically correct. There's a test specifying `IBM964` in `sun.nio.cs.TestIBMBugs.java`, but not sure it tests both paths or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/6110 From rriggs at openjdk.java.net Mon Oct 25 18:04:11 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 25 Oct 2021 18:04:11 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6110 From iris at openjdk.java.net Mon Oct 25 18:08:04 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 25 Oct 2021 18:08:04 GMT Subject: RFR: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6110 From bpb at openjdk.java.net Mon Oct 25 19:56:03 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 25 Oct 2021 19:56:03 GMT Subject: RFR: 8275840: Testing FileChannel.transferTo(FileChannel) with more than 2 GB of data In-Reply-To: References: Message-ID: On Sat, 23 Oct 2021 15:51:20 GMT, Markus KARG wrote: > Testing `FileChannel.transferTo(FileChannel)` with more than 2 GB of data is covering the case that *multiple* iterations of `FileChannel.transferTo(FileChannel)` are actually performed by the test. > > This change was requested Alan Bateman @AlanBateman. test/jdk/java/nio/channels/Channels/TransferTo.java line 147: > 145: // performing actual transfer, effectively by multiple invocations of Filechannel.transferTo(FileChannel) > 146: InputStream inputStream = Channels.newInputStream(FileChannel.open(sourceFile)); > 147: OutputStream outputStream = Channels.newOutputStream(FileChannel.open(targetFile, StandardOpenOption.WRITE)); It would probably be better to use a try-with-resources statement here to cleanly close the streams. ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From bpb at openjdk.java.net Mon Oct 25 20:59:10 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 25 Oct 2021 20:59:10 GMT Subject: RFR: 8275840: Testing FileChannel.transferTo(FileChannel) with more than 2 GB of data In-Reply-To: References: Message-ID: On Sat, 23 Oct 2021 15:51:20 GMT, Markus KARG wrote: > Testing `FileChannel.transferTo(FileChannel)` with more than 2 GB of data is covering the case that *multiple* iterations of `FileChannel.transferTo(FileChannel)` are actually performed by the test. > > This change was requested Alan Bateman @AlanBateman. test/jdk/java/nio/channels/Channels/TransferTo.java line 151: > 149: > 150: // comparing reported transferred bytes, must be 3 GB > 151: assertEquals(count, 3L * 1024 * 1024 * 1024); Also it would be better to use constants. One option is int NUM_WRITES = 3*1024; int BYTES_PER_WRITE = 1024*1024; in which case the second parameter of the first `assertEquals()` would be `(long)NUM_WRITES*BYTES_PER_WRITE`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From serb at openjdk.java.net Mon Oct 25 21:22:32 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 25 Oct 2021 21:22:32 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments Thank you for clarification. ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6045 From duke at openjdk.java.net Tue Oct 26 06:59:35 2021 From: duke at openjdk.java.net (Markus KARG) Date: Tue, 26 Oct 2021 06:59:35 GMT Subject: RFR: 8275840: Testing FileChannel.transferTo(FileChannel) with more than 2 GB of data [v2] In-Reply-To: References: Message-ID: > Testing `FileChannel.transferTo(FileChannel)` with more than 2 GB of data is covering the case that *multiple* iterations of `FileChannel.transferTo(FileChannel)` are actually performed by the test. > > This change was requested Alan Bateman @AlanBateman. Markus KARG has updated the pull request incrementally with two additional commits since the last revision: - Also it would be better to use constants. - It would probably be better to use a try-with-resources statement here to cleanly close the streams. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6093/files - new: https://git.openjdk.java.net/jdk/pull/6093/files/774078b6..04154625 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6093&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6093&range=00-01 Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/6093.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6093/head:pull/6093 PR: https://git.openjdk.java.net/jdk/pull/6093 From duke at openjdk.java.net Tue Oct 26 06:59:36 2021 From: duke at openjdk.java.net (Markus KARG) Date: Tue, 26 Oct 2021 06:59:36 GMT Subject: RFR: 8275840: Testing FileChannel.transferTo(FileChannel) with more than 2 GB of data [v2] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 19:53:01 GMT, Brian Burkhalter wrote: >> Markus KARG has updated the pull request incrementally with two additional commits since the last revision: >> >> - Also it would be better to use constants. >> - It would probably be better to use a try-with-resources statement here to cleanly close the streams. > > test/jdk/java/nio/channels/Channels/TransferTo.java line 147: > >> 145: // performing actual transfer, effectively by multiple invocations of Filechannel.transferTo(FileChannel) >> 146: InputStream inputStream = Channels.newInputStream(FileChannel.open(sourceFile)); >> 147: OutputStream outputStream = Channels.newOutputStream(FileChannel.open(targetFile, StandardOpenOption.WRITE)); > > It would probably be better to use a try-with-resources statement here to cleanly close the streams. Done in b12d39c2ca870d6cdc2bc8e1ae123b80a0517479. > test/jdk/java/nio/channels/Channels/TransferTo.java line 151: > >> 149: >> 150: // comparing reported transferred bytes, must be 3 GB >> 151: assertEquals(count, 3L * 1024 * 1024 * 1024); > > Also it would be better to use constants. One option is > > int NUM_WRITES = 3*1024; > int BYTES_PER_WRITE = 1024*1024; > > in which case the second parameter of the first `assertEquals()` would be `(long)NUM_WRITES*BYTES_PER_WRITE`. Done in b12d39c2ca870d6cdc2bc8e1ae123b80a0517479. ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From dfuchs at openjdk.java.net Tue Oct 26 10:46:09 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 26 Oct 2021 10:46:09 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments src/java.base/share/classes/java/io/Console.java line 590: > 588: if (cs == null) { > 589: cs = Charset.forName(StaticProperty.nativeEncoding(), > 590: Charset.defaultCharset()); I assume that `StaticProperty.nativeEncoding()` will never be `null`? Otherwise an IAE would be thrown here where previously `Charset.defaultCharset()` would be used. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Tue Oct 26 12:36:20 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 26 Oct 2021 12:36:20 GMT Subject: Integrated: 8275767: JDK source code contains redundant boolean operations in jdk.charsets In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote: > Trivial clean-up. This pull request has now been integrated. Changeset: 63e0f344 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/63e0f344e9a2da135c76caff11e437dfc40408a6 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8275767: JDK source code contains redundant boolean operations in jdk.charsets Reviewed-by: lancea, rriggs, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/6110 From naoto at openjdk.java.net Tue Oct 26 13:02:16 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 26 Oct 2021 13:02:16 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 10:42:49 GMT, Daniel Fuchs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflecting review comments > > src/java.base/share/classes/java/io/Console.java line 590: > >> 588: if (cs == null) { >> 589: cs = Charset.forName(StaticProperty.nativeEncoding(), >> 590: Charset.defaultCharset()); > > I assume that `StaticProperty.nativeEncoding()` will never be `null`? Otherwise an IAE would be thrown here where previously `Charset.defaultCharset()` would be used. Yes. `StaticProperty.nativeEncoding()` caches the value to `native.encoding` system property. The value is not optional, so it should be considered an error if `StaticProperty.nativeEncoding()` returned `null`. https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/System.html#native.encoding ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From dfuchs at openjdk.java.net Tue Oct 26 13:21:13 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 26 Oct 2021 13:21:13 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: <8L1W2kyFbAv3m7lxkWXUCy_015_ux9vZfhMLX--nUas=.ab4e6845-25c3-4527-b8cf-42302eaa6a70@github.com> On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote: >> During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From dfuchs at openjdk.java.net Tue Oct 26 13:21:14 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 26 Oct 2021 13:21:14 GMT Subject: RFR: 8270490: Charset.forName() taking fallback default value [v4] In-Reply-To: References: Message-ID: <9THjSfJ50FMcPGdFjqjdPXk6m_JfBvqwgHkiRGciU_c=.1a094cbe-69d8-4433-85e3-cb09318f874d@github.com> On Tue, 26 Oct 2021 12:59:11 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/io/Console.java line 590: >> >>> 588: if (cs == null) { >>> 589: cs = Charset.forName(StaticProperty.nativeEncoding(), >>> 590: Charset.defaultCharset()); >> >> I assume that `StaticProperty.nativeEncoding()` will never be `null`? Otherwise an IAE would be thrown here where previously `Charset.defaultCharset()` would be used. > > Yes. `StaticProperty.nativeEncoding()` caches the value to `native.encoding` system property. The value is not optional, so it should be considered an error if `StaticProperty.nativeEncoding()` returned `null`. > https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/System.html#native.encoding Thanks for the clarification. ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From naoto at openjdk.java.net Tue Oct 26 18:26:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 26 Oct 2021 18:26:09 GMT Subject: RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. > > Testing: tier1-3 Looks good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6102 From rriggs at openjdk.java.net Tue Oct 26 19:00:15 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 26 Oct 2021 19:00:15 GMT Subject: RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. > > Testing: tier1-3 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6102 From alanb at openjdk.java.net Tue Oct 26 19:08:15 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 26 Oct 2021 19:08:15 GMT Subject: RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings In-Reply-To: References: Message-ID: <7GvaEmUjCwTZUQVIo09tAKMT1rwqsmfdZy-gA-Q5fk0=.44e2b58d-573f-4fcd-bc83-5e59fad9a422@github.com> On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. > > Testing: tier1-3 Good work ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6102 From bpb at openjdk.java.net Tue Oct 26 21:17:12 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 26 Oct 2021 21:17:12 GMT Subject: RFR: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel [v4] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 16:40:43 GMT, Brian Burkhalter wrote: >> Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 4619075: Move read-only check to before read loop This PR is withdrawn for several reasons: - As covariant overrides are not supported for static methods, no appealing options remain for new API points. - The scatter-gather methods in other APIs such as for datagram, file, and socket channels map naturally to native system calls such as `readv(2)` and `writev(2)` which is not the case here so the operations are not atomic. - The implementation is subject to complex problems if an exception is encountered before all bytes have been read or written. - There is a lack of clear demand for this functionality. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From bpb at openjdk.java.net Tue Oct 26 21:17:13 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 26 Oct 2021 21:17:13 GMT Subject: Withdrawn: 4619075: (ch) newChannel() should return Gathering/ScatteringByteChannel In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 02:04:37 GMT, Brian Burkhalter wrote: > Modify `Channels.newChannel(InputStream)` and `Channels.newChannel(OutputStream)` to return `ScatteringByteChannel` and `GatheringByteChannel`, respectively. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5922 From redestad at openjdk.java.net Wed Oct 27 10:11:16 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 27 Oct 2021 10:11:16 GMT Subject: RFR: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. > > Testing: tier1-3 Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/6102 From redestad at openjdk.java.net Wed Oct 27 10:11:16 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 27 Oct 2021 10:11:16 GMT Subject: Integrated: 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote: > Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`: > > Before: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 3.021 ? 0.120 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 47.793 ? 1.942 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 49.598 ? 2.006 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 68.709 ? 5.019 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 48.033 ? 1.651 us/op > > > Patched: > > Benchmark (size) (type) Mode Cnt Score Error Units > CharsetEncodeDecode.encode 16384 ISO-8859-1 avgt 30 2.856 ? 0.078 us/op > CharsetEncodeDecode.encode 16384 Shift-JIS avgt 30 5.287 ? 0.209 us/op > CharsetEncodeDecode.encode 16384 GB2312 avgt 30 5.490 ? 0.251 us/op > CharsetEncodeDecode.encode 16384 EUC-JP avgt 30 7.657 ? 0.368 us/op > CharsetEncodeDecode.encode 16384 EUC-KR avgt 30 5.718 ? 0.267 us/op > > > The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations. > > Testing: tier1-3 This pull request has now been integrated. Changeset: 6c05cc9d Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/6c05cc9d15fb6014b8293a66ef132f3461badca1 Stats: 35 lines in 5 files changed: 24 ins; 4 del; 7 mod 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings Reviewed-by: naoto, rriggs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/6102 From naoto at openjdk.java.net Wed Oct 27 12:43:22 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 27 Oct 2021 12:43:22 GMT Subject: Integrated: 8270490: Charset.forName() taking fallback default value In-Reply-To: References: Message-ID: <-gFztgSCXQOYd4c0MrhisA2hISZu8KuhLShRNLff3As=.29e9193f-108b-4c7a-bd91-8feebcb53d15@github.com> On Wed, 20 Oct 2021 17:23:36 GMT, Naoto Sato wrote: > During the review of JEP 400, a proposal to provide an overloaded method to `Charset.forName()` was suggested [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This PR is to implement the proposal. A CSR is also drafted as https://bugs.openjdk.java.net/browse/JDK-8275348 This pull request has now been integrated. Changeset: 168081ef Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/168081efc8af1f5d1d7524246eb4a0675bd49ae0 Stats: 114 lines in 3 files changed: 106 ins; 5 del; 3 mod 8270490: Charset.forName() taking fallback default value Reviewed-by: joehw, rriggs, serb, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/6045 From bpb at openjdk.java.net Thu Oct 28 20:04:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 28 Oct 2021 20:04:43 GMT Subject: RFR: 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer Message-ID: Please consider this minor change which would dispense with a vestigial constant. ------------- Commit messages: - 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer Changes: https://git.openjdk.java.net/jdk/pull/6163/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6163&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276128 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6163.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6163/head:pull/6163 PR: https://git.openjdk.java.net/jdk/pull/6163 From lancea at openjdk.java.net Thu Oct 28 20:08:10 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 28 Oct 2021 20:08:10 GMT Subject: RFR: 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 19:58:47 GMT, Brian Burkhalter wrote: > Please consider this minor change which would dispense with a vestigial constant. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6163 From iris at openjdk.java.net Thu Oct 28 20:39:14 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 28 Oct 2021 20:39:14 GMT Subject: RFR: 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 19:58:47 GMT, Brian Burkhalter wrote: > Please consider this minor change which would dispense with a vestigial constant. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6163 From alanb at openjdk.java.net Fri Oct 29 06:59:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 29 Oct 2021 06:59:14 GMT Subject: RFR: 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 19:58:47 GMT, Brian Burkhalter wrote: > Please consider this minor change which would dispense with a vestigial constant. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6163 From bpb at openjdk.java.net Fri Oct 29 16:15:24 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 29 Oct 2021 16:15:24 GMT Subject: Integrated: 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer In-Reply-To: References: Message-ID: <5ict6ORnj9c6FnpW41rB98H9rlYHUxETJIzy_srXVZw=.a6077577-c14e-445d-9cc8-48b73c592c26@github.com> On Thu, 28 Oct 2021 19:58:47 GMT, Brian Burkhalter wrote: > Please consider this minor change which would dispense with a vestigial constant. This pull request has now been integrated. Changeset: 5facaa24 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/5facaa243aef6ad00cf71a047d0325710ce1f0a8 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer Reviewed-by: lancea, iris, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/6163 From bpb at openjdk.java.net Fri Oct 29 22:21:30 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 29 Oct 2021 22:21:30 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v9] In-Reply-To: <8vwe-oQ5ilpMKuep4zSHycQisXMIFImfyE4hRVFvCS8=.c0fbf5b2-ccf3-46f4-bce1-6bb5fb3403e3@github.com> References: <8vwe-oQ5ilpMKuep4zSHycQisXMIFImfyE4hRVFvCS8=.c0fbf5b2-ccf3-46f4-bce1-6bb5fb3403e3@github.com> Message-ID: On Sat, 31 Jul 2021 00:59:19 GMT, Brian Burkhalter wrote: >> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`. >> >> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.) >> >> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension. >> >> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero. >> >> The behavior of the proposed method for some example cases is as: >> >> >> . -> >> .. -> >> .a.b -> b >> ...... -> >> .....a -> a >> ....a.b -> b >> ..foo -> foo >> test.rb -> rb >> a/b/d/test.rb -> rb >> .a/b/d/test.rb -> rb >> foo. -> >> test -> >> .profile -> >> .profile.sh -> sh >> ..foo -> foo >> .....foo -> foo >> .vimrc -> >> test. -> >> test.. -> >> test... -> >> foo.tar.gz -> gz >> foo.bar. -> >> image.jpg -> jpg >> music.mp3 -> mp3 >> video.mp4 -> mp4 >> document.txt -> txt >> foo.tar.gz -> gz >> foo.bar. -> > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - 8057113: Optimistically update @since tag to 18 > - Merge > - 8057113: Change first sentence; change param name > - 8057113: Change Path.getExtension() to accept a default return value in case the extension is indeterminate > - 8057113: Tweak spec again, and @implSpec code > - 8057113: Add @since tag > - 8057113: Tweak first sentence of spec > - 8057113: Handle getFileName() == null; revise spec > - 8057113: Changes pursuant to PR conversation > - 8057113: (fs) Path should have a method to obtain the filename extension continue; ------------- PR: https://git.openjdk.java.net/jdk/pull/2319 From duke at openjdk.java.net Sat Oct 30 10:04:12 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 30 Oct 2021 10:04:12 GMT Subject: RFR: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB [v2] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 06:59:35 GMT, Markus KARG wrote: >> Testing `FileChannel.transferTo(FileChannel)` with more than 2 GB of data is covering the case that *multiple* iterations of `FileChannel.transferTo(FileChannel)` are actually performed by the test. >> >> This change was requested Alan Bateman @AlanBateman. > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Also it would be better to use constants. > - It would probably be better to use a try-with-resources statement here to cleanly close the streams. All requested changes are done meanwhile. If no more changes are needed, I kindly like to request approvial of this PR. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From duke at openjdk.java.net Sun Oct 31 10:52:11 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 31 Oct 2021 10:52:11 GMT Subject: RFR: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB [v2] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 06:59:35 GMT, Markus KARG wrote: >> Testing `FileChannel.transferTo(FileChannel)` with more than 2 GB of data is covering the case that *multiple* iterations of `FileChannel.transferTo(FileChannel)` are actually performed by the test. >> >> This change was requested Alan Bateman @AlanBateman. > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Also it would be better to use constants. > - It would probably be better to use a try-with-resources statement here to cleanly close the streams. @shipilev @AlanBateman Kindly requesting appproval of this PR. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From lancea at openjdk.java.net Sun Oct 31 11:54:16 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 31 Oct 2021 11:54:16 GMT Subject: RFR: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB [v2] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 06:59:35 GMT, Markus KARG wrote: >> Testing `FileChannel.transferTo(FileChannel)` with more than 2 GB of data is covering the case that *multiple* iterations of `FileChannel.transferTo(FileChannel)` are actually performed by the test. >> >> This change was requested Alan Bateman @AlanBateman. > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Also it would be better to use constants. > - It would probably be better to use a try-with-resources statement here to cleanly close the streams. test/jdk/java/nio/channels/Channels/TransferTo.java line 143: > 141: // writing 3 GB of random bytes into source file > 142: int NUM_WRITES = 3 * 1024; > 143: int BYTES_PER_WRITE = 1024 * 1024; We typically do not capitalize local variables, we capitalize constants(Brian was suggesting the use of constants). Using constants adds consistency with their use elsewhere. If you choose to use a local variable, the variable name should not be capitalized test/jdk/java/nio/channels/Channels/TransferTo.java line 155: > 153: > 154: // comparing reported transferred bytes, must be 3 GB > 155: assertEquals(count, (long) NUM_WRITES * BYTES_PER_WRITE); This could also be a constant (similar to MAX_SIZE_INCR) ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From alanb at openjdk.java.net Sun Oct 31 17:24:13 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 31 Oct 2021 17:24:13 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v3] In-Reply-To: <8ik0aKwFgv4ltDFVGqHFWSZqcW_ZeaCWp9zjjyTVbWM=.61b471ce-ac80-4dd0-a264-739b31346aba@github.com> References: <8ik0aKwFgv4ltDFVGqHFWSZqcW_ZeaCWp9zjjyTVbWM=.61b471ce-ac80-4dd0-a264-739b31346aba@github.com> Message-ID: On Thu, 21 Oct 2021 21:36:37 GMT, Brian Burkhalter wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java line 64: >> >>> 62: String path = join(file.getPathForWin32Calls(), name); >>> 63: WindowsPath wp = WindowsPath.createFromNormalizedPath(wfs, path); >>> 64: return wp.getPathForWin32Calls(); >> >> I think we can simplify this to avoid most of the conversions, I'll get back to you soon with a proposal for this. > > Do you have any further suggestions on this? Thanks. One thing I'm still mulling over here is whether there should be a check that namePath only has one name element. That is, I think "join" should probably reject the name if it has a root component or has more than one name element. That would replace the check for an absolute path because that would imply a root component. ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From duke at openjdk.java.net Sun Oct 31 17:43:41 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 31 Oct 2021 17:43:41 GMT Subject: RFR: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB [v3] In-Reply-To: References: Message-ID: > Testing `FileChannel.transferTo(FileChannel)` with more than 2 GB of data is covering the case that *multiple* iterations of `FileChannel.transferTo(FileChannel)` are actually performed by the test. > > This change was requested Alan Bateman @AlanBateman. Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Constants instead of local variables Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6093/files - new: https://git.openjdk.java.net/jdk/pull/6093/files/04154625..126e4877 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6093&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6093&range=01-02 Stats: 7 lines in 1 file changed: 4 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6093.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6093/head:pull/6093 PR: https://git.openjdk.java.net/jdk/pull/6093 From duke at openjdk.java.net Sun Oct 31 17:43:45 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 31 Oct 2021 17:43:45 GMT Subject: RFR: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB [v2] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 06:59:35 GMT, Markus KARG wrote: >> Testing `FileChannel.transferTo(FileChannel)` with more than 2 GB of data is covering the case that *multiple* iterations of `FileChannel.transferTo(FileChannel)` are actually performed by the test. >> >> This change was requested Alan Bateman @AlanBateman. > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Also it would be better to use constants. > - It would probably be better to use a try-with-resources statement here to cleanly close the streams. @LanceAndersen Thank you for your improvement proposals, which both are fixed in https://github.com/openjdk/jdk/pull/6093/commits/126e4877361ac7e3ab82101fee78d7d50c5733ac. ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From duke at openjdk.java.net Sun Oct 31 17:43:50 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 31 Oct 2021 17:43:50 GMT Subject: RFR: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB [v2] In-Reply-To: References: Message-ID: On Sun, 31 Oct 2021 11:34:26 GMT, Lance Andersen wrote: >> Markus KARG has updated the pull request incrementally with two additional commits since the last revision: >> >> - Also it would be better to use constants. >> - It would probably be better to use a try-with-resources statement here to cleanly close the streams. > > test/jdk/java/nio/channels/Channels/TransferTo.java line 143: > >> 141: // writing 3 GB of random bytes into source file >> 142: int NUM_WRITES = 3 * 1024; >> 143: int BYTES_PER_WRITE = 1024 * 1024; > > We typically do not capitalize local variables, we capitalize constants(Brian was suggesting the use of constants). > > Using constants adds consistency with their use elsewhere. > > If you choose to use a local variable, the variable name should not be capitalized Done in https://github.com/openjdk/jdk/pull/6093/commits/126e4877361ac7e3ab82101fee78d7d50c5733ac. > test/jdk/java/nio/channels/Channels/TransferTo.java line 155: > >> 153: >> 154: // comparing reported transferred bytes, must be 3 GB >> 155: assertEquals(count, (long) NUM_WRITES * BYTES_PER_WRITE); > > This could also be a constant (similar to MAX_SIZE_INCR) Done in https://github.com/openjdk/jdk/pull/6093/commits/126e4877361ac7e3ab82101fee78d7d50c5733ac. ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From alanb at openjdk.java.net Sun Oct 31 19:03:11 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 31 Oct 2021 19:03:11 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v4] In-Reply-To: <1AR4tgaz1JdXutbQMh7FNoG0SHk1nHznl5H9n2Jzk3U=.545d612d-8eee-4290-8571-e5a9e18fe680@github.com> References: <1AR4tgaz1JdXutbQMh7FNoG0SHk1nHznl5H9n2Jzk3U=.545d612d-8eee-4290-8571-e5a9e18fe680@github.com> Message-ID: <0y8PzTwDz5nw7mqYSZchji3AAyqB-d-7E-8jGf02tHk=.2f7b7363-794e-47ae-8032-770a704a6f04@github.com> On Mon, 25 Oct 2021 16:57:41 GMT, Brian Burkhalter wrote: >> Please consider this patch which would improve the performance of >> `FileChannel.transferTo()` on macOS and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274112: Make transferTo0() static; remove check for null FileDescriptor The latest version looks okay but I'm wondering if we can move transfer_read_write out of the native code. As you know, in this area we try to have the JNI methods do a single syscall. With this change we've put a transfer loop into the native code when it should probably be in Java. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623