From alanb at openjdk.java.net Mon Nov 1 07:44:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 1 Nov 2021 07:44:09 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 10:49:19 GMT, Markus KARG wrote: > @shipilev @AlanBateman Kindly requesting appproval of this PR. :-) Thanks for coming back to this >2GB file test as that will test the loop. I see @LanceAndersen and @bplb are already looking at the test changes so I'll leave it to them. ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From mcimadamore at openjdk.java.net Mon Nov 1 12:05:32 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 1 Nov 2021 12:05:32 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10] 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 pull request now contains 17 commits: - Add cache for memory address var handles - Merge branch 'master' into JEP-419 - 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 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/5bb1992b...9b519343 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5907/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=09 Stats: 14497 lines in 189 files changed: 6773 ins; 5149 del; 2575 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 Mon Nov 1 16:48:16 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 1 Nov 2021 16:48:16 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: On Sun, 31 Oct 2021 17:43:41 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 one additional commit since the last revision: > > Constants instead of local variables > > Signed-off-by: Markus Karg test/jdk/java/nio/channels/Channels/TransferTo.java line 152: > 150: long count; > 151: try (InputStream inputStream = Channels.newInputStream(FileChannel.open(sourceFile)); > 152: OutputStream outputStream = Channels.newOutputStream(FileChannel.open(targetFile, StandardOpenOption.WRITE))) { I think that this needs to be indented. ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From mcimadamore at openjdk.java.net Mon Nov 1 17:15:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 1 Nov 2021 17:15:55 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v11] In-Reply-To: References: Message-ID: <8DLqVOZo6ZXYqntQe91nI4wIKu0_gn0DY-l8MA2rznM=.fdab6f3c-119e-492d-b61c-6314d51cdd58@github.com> > 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 liveness issue with loader lookups ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/9b519343..17f45861 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=09-10 Stats: 191 lines in 6 files changed: 187 ins; 0 del; 4 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 Mon Nov 1 18:37:39 2021 From: duke at openjdk.java.net (Markus KARG) Date: Mon, 1 Nov 2021 18:37:39 GMT Subject: RFR: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB [v4] 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: Indentation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6093/files - new: https://git.openjdk.java.net/jdk/pull/6093/files/126e4877..435690c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6093&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6093&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 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 Mon Nov 1 18:37:43 2021 From: duke at openjdk.java.net (Markus KARG) Date: Mon, 1 Nov 2021 18:37:43 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: On Mon, 1 Nov 2021 16:45:15 GMT, Brian Burkhalter wrote: >> 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 > > test/jdk/java/nio/channels/Channels/TransferTo.java line 152: > >> 150: long count; >> 151: try (InputStream inputStream = Channels.newInputStream(FileChannel.open(sourceFile)); >> 152: OutputStream outputStream = Channels.newOutputStream(FileChannel.open(targetFile, StandardOpenOption.WRITE))) { > > I think that this needs to be indented. Thanks, done in https://github.com/openjdk/jdk/pull/6093/commits/435690c6539e74b08162b63d0b896545c5ee3de2. ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From lancea at openjdk.java.net Mon Nov 1 21:39:19 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 1 Nov 2021 21:39:19 GMT Subject: RFR: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB [v4] In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 18:37:39 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 one additional commit since the last revision: > > Indentation Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From bpb at openjdk.java.net Mon Nov 1 22:34:13 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 1 Nov 2021 22:34:13 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: 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 I believe that prior to publishing this PR I tested the case of doing the read-write transfer in Java and it did not afford the same sort of performance improvement as what is proposed here. This version was inspired more by the native code underlying the Unix implementation of Files.copy() (UnixCopyFile.c) which has exactly the same sort of native read-write loop in it. The question here then becomes whether the performance improvement is worth the extra native code. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From mcimadamore at openjdk.java.net Mon Nov 1 22:36:40 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 1 Nov 2021 22:36:40 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12] 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: Tweak javadoc of loaderLookup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/17f45861..7cf4fcd9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=10-11 Stats: 2 lines in 1 file changed: 0 ins; 0 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 bpb at openjdk.java.net Mon Nov 1 23:53:31 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 1 Nov 2021 23:53:31 GMT Subject: RFR: 8276260: (se) Remove java/nio/channels/Selector/Wakeup.java from ProblemList (win) Message-ID: This request would reinstate the JDK test java/nio/channels/Selector/Wakeup.java in testing on Windows. ------------- Commit messages: - 8276260: (se) Remove java/nio/channels/Selector/Wakeup.java from ProblemList (win) Changes: https://git.openjdk.java.net/jdk/pull/6201/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6201&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276260 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6201/head:pull/6201 PR: https://git.openjdk.java.net/jdk/pull/6201 From psandoz at openjdk.java.net Tue Nov 2 00:27:23 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 2 Nov 2021 00:27:23 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10] In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 12:05:32 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 with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Add cache for memory address var handles > - Merge branch 'master' into JEP-419 > - 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 > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/5bb1992b...9b519343 src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line 111: > 109: class VarHandleCache { > 110: private static final Map handleMap = new ConcurrentHashMap<>(); > 111: private static final Map handleMapNoAlignCheck = new ConcurrentHashMap<>(); Something to consider later if this is an issue. Since the number of `ValueLayout` instances is fixed, carrier x order = 18, we can use stable arrays with ordinals on the instances. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From bpb at openjdk.java.net Tue Nov 2 00:28:56 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 2 Nov 2021 00:28:56 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v4] In-Reply-To: References: Message-ID: > Modify `sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsPath,String)` to handle file names which exceed the limit. 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 five additional commits since the last revision: - Merge - 8273922: Change absolute path check to check for name count and root presence - 8273922: Make join() reject absolute path in 1nth in 'name' parameter - 8273922: Add bug ID to @bug in test - 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5594/files - new: https://git.openjdk.java.net/jdk/pull/5594/files/5be22533..14f5a7aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5594&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5594&range=02-03 Stats: 86384 lines in 2188 files changed: 61473 ins; 14946 del; 9965 mod Patch: https://git.openjdk.java.net/jdk/pull/5594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5594/head:pull/5594 PR: https://git.openjdk.java.net/jdk/pull/5594 From alanb at openjdk.java.net Tue Nov 2 06:35:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 2 Nov 2021 06:35:14 GMT Subject: RFR: 8276260: (se) Remove java/nio/channels/Selector/Wakeup.java from ProblemList (win) In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 23:11:38 GMT, Brian Burkhalter wrote: > This request would reinstate the JDK test java/nio/channels/Selector/Wakeup.java in testing on Windows. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6201 From alanb at openjdk.java.net Tue Nov 2 07:27:19 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 2 Nov 2021 07:27:19 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v4] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 00:28:56 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge > - 8273922: Change absolute path check to check for name count and root presence > - 8273922: Make join() reject absolute path in 1nth in 'name' parameter > - 8273922: Add bug ID to @bug in test > - 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) Thanks for the update, I think we are close to being done. src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java line 61: > 59: WindowsPath namePath = WindowsPath.parse(wfs, name); > 60: if (namePath.getRoot() != null) > 61: throw new IllegalArgumentException("'name' is not relative"); The exception message should "has a root component" because a name such as "C:foo" is relative. src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java line 63: > 61: throw new IllegalArgumentException("'name' is not relative"); > 62: if (namePath.getNameCount() != 1) > 63: throw new IllegalArgumentException("'name' has more than one element"); Alternatively, just check if getParent() returns null. ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From mcimadamore at openjdk.java.net Tue Nov 2 10:34:18 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 2 Nov 2021 10:34:18 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 00:24:12 GMT, Paul Sandoz wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - Add cache for memory address var handles >> - Merge branch 'master' into JEP-419 >> - 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 >> - ... and 7 more: https://git.openjdk.java.net/jdk/compare/5bb1992b...9b519343 > > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line 111: > >> 109: class VarHandleCache { >> 110: private static final Map handleMap = new ConcurrentHashMap<>(); >> 111: private static final Map handleMapNoAlignCheck = new ConcurrentHashMap<>(); > > Something to consider later if this is an issue. Since the number of `ValueLayout` instances is fixed, carrier x order = 18, we can use stable arrays with ordinals on the instances. What about alignment? ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From psandoz at openjdk.java.net Tue Nov 2 15:44:13 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 2 Nov 2021 15:44:13 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10] In-Reply-To: References: Message-ID: <5onID0SnzIoPH5_Le4f71eC5ll_zGn0DQecQVpL1jDM=.43d7b2af-185a-4251-828f-058da6a69115@github.com> On Tue, 2 Nov 2021 10:30:42 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line 111: >> >>> 109: class VarHandleCache { >>> 110: private static final Map handleMap = new ConcurrentHashMap<>(); >>> 111: private static final Map handleMapNoAlignCheck = new ConcurrentHashMap<>(); >> >> Something to consider later if this is an issue. Since the number of `ValueLayout` instances is fixed, carrier x order = 18, we can use stable arrays with ordinals on the instances. > > What about alignment? Drat, `skipAlignmentCheck` misled me but perhaps there is still benefit for common constants with 8 bit and size alignment and fallback otherwise. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From psandoz at openjdk.java.net Tue Nov 2 15:44:12 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 2 Nov 2021 15:44:12 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12] In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 22:36:40 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: > > Tweak javadoc of loaderLookup Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From bpb at openjdk.java.net Tue Nov 2 16:31:18 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 2 Nov 2021 16:31:18 GMT Subject: Integrated: 8276260: (se) Remove java/nio/channels/Selector/Wakeup.java from ProblemList (win) In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 23:11:38 GMT, Brian Burkhalter wrote: > This request would reinstate the JDK test java/nio/channels/Selector/Wakeup.java in testing on Windows. This pull request has now been integrated. Changeset: fa4ce824 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/fa4ce824a39264e765b8236ee58b1f28faa371e0 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8276260: (se) Remove java/nio/channels/Selector/Wakeup.java from ProblemList (win) Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/6201 From prappo at openjdk.java.net Tue Nov 2 16:54:28 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 2 Nov 2021 16:54:28 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base Message-ID: This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: $ sh ./bin/blessed-modifier-order.sh src/java.base The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/6213/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6213&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276348 Stats: 39 lines in 21 files changed: 0 ins; 0 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/6213.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6213/head:pull/6213 PR: https://git.openjdk.java.net/jdk/pull/6213 From prappo at openjdk.java.net Tue Nov 2 16:58:11 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 2 Nov 2021 16:58:11 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? > > As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. > > [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) > [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html A colleague suggested that I should clarify that the `blessed-modifier-order.sh` script that I used is available in the JDK repo at https://github.com/openjdk/jdk/blob/01105d6985b39d4064b9066eab3612da5a401685/bin/blessed-modifier-order.sh. That script was contributed by Martin Buchholz in JDK-8136656 in 2015. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From dfuchs at openjdk.java.net Tue Nov 2 17:13:10 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 2 Nov 2021 17:13:10 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? > > As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. > > [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) > [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html Marked as reviewed by dfuchs (Reviewer). LGTM ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From rriggs at openjdk.java.net Tue Nov 2 17:17:18 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 2 Nov 2021 17:17:18 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? > > As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. > > [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) > [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html src/java.base/share/classes/java/lang/Object.java line 282: > 280: *
  • For objects of type {@code Class,} by executing a > 281: * static synchronized method of that class. > 282: * In comments, I think the 'synchronized static 'reads better, the conventional order is for the code. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From darcy at openjdk.java.net Tue Nov 2 17:24:14 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 2 Nov 2021 17:24:14 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? > > As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. > > [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) > [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From iris at openjdk.java.net Tue Nov 2 17:24:14 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 2 Nov 2021 17:24:14 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? > > As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. > > [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) > [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From jvernee at openjdk.java.net Tue Nov 2 17:32:17 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 2 Nov 2021 17:32:17 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12] In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 22:36:40 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: > > Tweak javadoc of loaderLookup Mostly some minor javadoc comments. src/java.base/share/classes/java/lang/Module.java line 32: > 30: import java.lang.annotation.Annotation; > 31: import java.lang.invoke.MethodHandle; > 32: import java.lang.invoke.VarHandle; These imports seem spurious now. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java line 177: > 175: } > 176: if (carrier.isPrimitive() && Wrapper.forPrimitiveType(carrier).bitWidth() != size && > 177: carrier != boolean.class && size != 8) { I find this condition hard to parse, I'd suggest re-writing it as: if (carrier.isPrimitive()) { long expectedSize = carrier == boolean.class ? 8 : Wrapper.forPrimitiveType(carrier).bitWidth(); if (size != expectedSize) { throw ... } } (Maybe even change the `if` to an `else` and combine it with the above if). src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java line 484: > 482: public static final class OfAddress extends ValueLayout { > 483: OfAddress(ByteOrder order) { > 484: super(MemoryAddress.class, order, Unsafe.ADDRESS_SIZE * 8); I see `Unsafe.ADDRESS_SIZE` used in several places, suggest to maybe add an `ADDRESS_SIZE_BITS` constants somewhere (it's a bit more readable). src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java line 42: > 40: final long blockSize; > 41: final long arenaSize; > 42: final ResourceScope scope; Could these field be made private? src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java line 88: > 86: if (size > arenaSize) { > 87: throw new OutOfMemoryError(); > 88: } Isn't this already covered by the `finally` block? Also, this seems to be checking the unaltered `size`, which I think should have been already done at the end of the previous `allocate` call right? src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java line 122: > 120: ResourceScopeImpl targetImpl = (ResourceScopeImpl)target; > 121: targetImpl.acquire0(); > 122: addCloseAction(targetImpl::release0); Maybe this should explicitly check if target is `null` (though the call to `acquire0` would also produce an NPE, the stack trace having Objects::requireNonNull in there would make the error more obvious I think). Suggestion: public void keepAlive(ResourceScope target) { Objects.requireNonNull(target); if (target == this) { throw new IllegalArgumentException("Invalid target scope."); } ResourceScopeImpl targetImpl = (ResourceScopeImpl)target; targetImpl.acquire0(); addCloseAction(targetImpl::release0); src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java line 101: > 99: int value; > 100: do { > 101: value = (int) STATE.getVolatile(jdk.internal.foreign.SharedScope.this); Doesn't need to be fully qualified I think? Suggestion: value = (int) STATE.getVolatile(this); src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java line 106: > 104: throw new IllegalStateException("Already closed"); > 105: } > 106: } while (!STATE.compareAndSet(jdk.internal.foreign.SharedScope.this, value, value - 1)); Same here Suggestion: } while (!STATE.compareAndSet(this, value, value - 1)); ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5907 From jvernee at openjdk.java.net Tue Nov 2 17:32:24 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 2 Nov 2021 17:32:24 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10] In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 12:05:32 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 with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Add cache for memory address var handles > - Merge branch 'master' into JEP-419 > - 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 > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/5bb1992b...9b519343 src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1586: > 1584: public void ensureCustomized(MethodHandle mh) { > 1585: mh.customize(); > 1586: } This is no longer needed, but it probably got picked up in the merge. src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java line 144: > 142: * @param mh the method handle > 143: */ > 144: void ensureCustomized(MethodHandle mh); Same here, no longer needed. (it was used by now removed upcall handler code. See https://github.com/openjdk/panama-foreign/pull/553) src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 107: > 105: * > 106: * @param offset offset in bytes (relative to this address). The final address of this read operation can be expressed as {@code toRowLongValue() + offset}. > 107: * @return a Java UTF-8 string containing all the bytes read from the given starting address ({@code toRowLongValue() + offset}) (see also comment on MemorySegment.getUtf8String) Suggestion: * @return a Java string constructed from the bytes read from the given starting address ({@code toRowLongValue() + offset}) src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 387: > 385: > 386: /** > 387: * Performs an element-wise bulk copy from given source segment to this segment. More specifically, the bytes at Suggestion: * Performs a byte-wise bulk copy from given source segment to this segment. More specifically, the bytes at src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 400: > 398: * a multiple of the source element layout size, if the source segment is incompatible with the alignment constraints > 399: * in the source element layout, or if this segment is incompatible with the alignment constraints > 400: * in the destination element layout. This speaks about element layouts, but I don't see any element layouts in the method implementation. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 633: > 631: * java.nio.charset.CharsetDecoder} class should be used when more control > 632: * over the decoding process is required. > 633: * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative()} segment, Suggestion: * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative() native} segment, src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 636: > 634: * the final address of this read operation can be expressed as {@code address().toRowLongValue() + offset}. > 635: * @return a Java UTF-8 string containing all the bytes read from the given starting address up to (but not including) > 636: * the first {@code '\0'} terminator character (assuming one is found). The phrase "a Java UTF-8 string" sounds strange to me, as Java Strings are not encoded in UTF-8. The string that is read is UTF-8 encoded, but then it is converted from UTF-8 to Java internal String encoding (UTF-16 or Latin1). I'd suggest just dropping the 'UTF-8', and changing 'containing all' to 'constructed from'. Suggestion: * @return a Java string constructed from the bytes read from the given starting address up to (but not including) * the first {@code '\0'} terminator character (assuming one is found). src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 652: > 650: * java.nio.charset.CharsetDecoder} class should be used when more control > 651: * over the decoding process is required. > 652: * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative()} segment, Suggestion: * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative() native} segment, src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 762: > 760: > 761: /** > 762: * Creates a new native memory segment with given size and resource scope, and whose base address is this address. Suggestion: * Creates a new native memory segment with given size and resource scope, and whose base address is the given address. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 769: > 767: * provided resource scope. > 768: *

    > 769: * Clients should ensure that the address and bounds refers to a valid region of memory that is accessible for reading and, Suggestion: * Clients should ensure that the address and bounds refer to a valid region of memory that is accessible for reading and, src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1035: > 1033: * > 1034: * @param layout the layout of the memory region to be read. > 1035: * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative()} segment, Suggestion: * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative() native} segment, src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1549: > 1547: * @param index index (relative to this segment). For instance, if this segment is a {@link #isNative()} segment, > 1548: * the final address of this write operation can be expressed as {@code address().toRowLongValue() + (index * layout.byteSize())}. > 1549: * @param value the byte value to be written. Suggestion: * @param value the address value to be written. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1563: > 1561: * Copies a number of elements from a source segment to a destination array, > 1562: * starting at a given segment offset (expressed in bytes), and a given array index, using the given source element layout. > 1563: * Supported array types are {@code byte[]}, {@code char[]},{@code short[]},{@code int[]},{@code float[]},{@code long[]} and {@code double[]}. Suggestion: * Supported array types are {@code byte[]}, {@code char[]}, {@code short[]}, {@code int[]}, {@code float[]}, {@code long[]} and {@code double[]}. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1604: > 1602: * Copies a number of elements from a source array to a destination segment, > 1603: * starting at a given array index, and a given segment offset (expressed in bytes), using the given destination element layout. > 1604: * Supported array types are {@code byte[]}, {@code char[]},{@code short[]},{@code int[]},{@code float[]},{@code long[]} and {@code double[]}. Suggestion: * Supported array types are {@code byte[]}, {@code char[]}, {@code short[]}, {@code int[]}, {@code float[]}, {@code long[]} and {@code double[]}. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 208: > 206: */ > 207: static ResourceScope newConfinedScope() { > 208: return ResourceScopeImpl.createConfined( Thread.currentThread(), null); Suggestion: return ResourceScopeImpl.createConfined(Thread.currentThread(), null); src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/VaList.java line 132: > 130: /** > 131: * Copies this variable argument list at its current position into a new variable argument list associated > 132: * with the same scope as this variable argument list. using the segment provided allocator. Copying is useful to I think ". using the segment provided allocator" can be removed. Seems like a leftover from when we had an overload that took an allocator. Suggestion: * with the same scope as this variable argument list. Copying is useful to ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From jvernee at openjdk.java.net Tue Nov 2 17:32:25 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 2 Nov 2021 17:32:25 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10] In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 15:38:18 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - Add cache for memory address var handles >> - Merge branch 'master' into JEP-419 >> - 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 >> - ... and 7 more: https://git.openjdk.java.net/jdk/compare/5bb1992b...9b519343 > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1035: > >> 1033: * >> 1034: * @param layout the layout of the memory region to be read. >> 1035: * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative()} segment, > > Suggestion: > > * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative() native} segment, Same suggestion with all the other getters/setters below (I assume you wanted to add text to the link here?) > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1549: > >> 1547: * @param index index (relative to this segment). For instance, if this segment is a {@link #isNative()} segment, >> 1548: * the final address of this write operation can be expressed as {@code address().toRowLongValue() + (index * layout.byteSize())}. >> 1549: * @param value the byte value to be written. > > Suggestion: > > * @param value the address value to be written. I think all the setters have this problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From alanb at openjdk.java.net Tue Nov 2 17:42:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 2 Nov 2021 17:42:14 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com> On Tue, 2 Nov 2021 17:13:47 GMT, Roger Riggs wrote: > In comments, I think the 'synchronized static 'reads better, the conventional order is for the code. I think Roger is right and maybe the change to the javadoc could be dropped from this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From prappo at openjdk.java.net Tue Nov 2 17:49:19 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 2 Nov 2021 17:49:19 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com> References: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com> Message-ID: On Tue, 2 Nov 2021 17:39:17 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/Object.java line 282: >> >>> 280: *

  • For objects of type {@code Class,} by executing a >>> 281: * static synchronized method of that class. >>> 282: * >> >> In comments, I think the 'synchronized static 'reads better, the conventional order is for the code. > >> In comments, I think the 'synchronized static 'reads better, the conventional order is for the code. > > I think Roger is right and maybe the change to the javadoc could be dropped from this patch. It's tough when a natural language clashes with a programming language. I appreciate that this particular clash might cause discomfort to native English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for adjective order.) That said, consider the following pragmatic aspect. Unless we change the script not to process prose in comments (btw, how would we do that?), every single time we run that script, that particular line in Object.java will need to be tracked and excluded. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From duke at openjdk.java.net Tue Nov 2 18:09:18 2021 From: duke at openjdk.java.net (Markus KARG) Date: Tue, 2 Nov 2021 18:09:18 GMT Subject: Integrated: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB In-Reply-To: References: Message-ID: <0Z568HdhydqqpuPlrxmSSTB9Fum_H-hsMInIUzLL7H4=.e8f59b6b-c573-4826-bc32-09aa136e5636@github.com> 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. This pull request has now been integrated. Changeset: 6a04899b Author: Markus Karg Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/6a04899ba1a62f52f7e28cc2ed72bdca115e6562 Stats: 35 lines in 1 file changed: 35 ins; 0 del; 0 mod 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From prappo at openjdk.java.net Tue Nov 2 18:22:12 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 2 Nov 2021 18:22:12 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com> Message-ID: On Tue, 2 Nov 2021 17:45:07 GMT, Pavel Rappo wrote: >>> In comments, I think the 'synchronized static 'reads better, the conventional order is for the code. >> >> I think Roger is right and maybe the change to the javadoc could be dropped from this patch. > > It's tough when a natural language clashes with a programming language. I appreciate that this particular clash might cause discomfort to native English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for adjective order.) That said, consider the following pragmatic aspect. Unless we change the script not to process prose in comments (btw, how would we do that?), every single time we run that script, that particular line in Object.java will need to be tracked and excluded. Here's a bit of archaeology. I found the original JDK-8136583 patch, which has moved from where it was in the RFR to https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/. That patch doesn't change Object.java. The RFR thread mentions neither that javadoc change nor any javadoc change for that matter. So either the script was different, or Martin filtered that line (from Object.java) out before creating the webrev. Now, in his followup thread on core-libs-dev, http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035273.html, Martin specifically pointed out javadoc changes and said that they seem fine to him. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From prr at openjdk.java.net Tue Nov 2 18:30:16 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 2 Nov 2021 18:30:16 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? > > As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. > > [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) > [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html JFYI a couple of times I've wondered if we regressed on this. I just ran the script on the desktop module and we havea few instances there too, so I've filed a clean up bug on it. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From rriggs at openjdk.java.net Tue Nov 2 18:52:20 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 2 Nov 2021 18:52:20 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com> Message-ID: On Tue, 2 Nov 2021 18:48:06 GMT, Mark Sheppard wrote: >> Here's a bit of archaeology. I found the original JDK-8136583 patch, which has moved from where it was in the RFR to https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/. That patch doesn't change Object.java. The RFR thread mentions neither that javadoc change nor any javadoc change for that matter. So either the script was different, or Martin filtered that line (from Object.java) out before creating the webrev. >> >> Now, in his followup thread on core-libs-dev, http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035273.html, Martin specifically pointed out javadoc changes and said that they seem fine to him. > > "to each his own". I think static synchronized reads best and more natural than synchronzied static. Also from a semantic point of view as it conveys class level characteristic thus lends static to having a prominence in specified order. Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression. All of the changes have to be manually reviewed by the author and then the reviewers. Checking unneeded changes is part of every mechanical change. The text being changed in the javadoc is the *spec*; that deserves special attention in review. But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From msheppar at openjdk.java.net Tue Nov 2 18:52:20 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Tue, 2 Nov 2021 18:52:20 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com> Message-ID: On Tue, 2 Nov 2021 18:17:36 GMT, Pavel Rappo wrote: >> It's tough when a natural language clashes with a programming language. I appreciate that this particular clash might cause discomfort to native English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for adjective order.) That said, consider the following pragmatic aspect. Unless we change the script not to process prose in comments (btw, how would we do that?), every single time we run that script, that particular line in Object.java will need to be tracked and excluded. > > Here's a bit of archaeology. I found the original JDK-8136583 patch, which has moved from where it was in the RFR to https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/. That patch doesn't change Object.java. The RFR thread mentions neither that javadoc change nor any javadoc change for that matter. So either the script was different, or Martin filtered that line (from Object.java) out before creating the webrev. > > Now, in his followup thread on core-libs-dev, http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035273.html, Martin specifically pointed out javadoc changes and said that they seem fine to him. "to each his own". I think static synchronized reads best and more natural than synchronzied static. Also from a semantic point of view as it conveys class level characteristic thus lends static to having a prominence in specified order. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From prappo at openjdk.java.net Tue Nov 2 19:18:15 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 2 Nov 2021 19:18:15 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com> Message-ID: On Tue, 2 Nov 2021 18:48:20 GMT, Roger Riggs wrote: > Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression. I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted. > But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English. I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From duke at openjdk.java.net Tue Nov 2 19:18:16 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 2 Nov 2021 19:18:16 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? > > As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. > > [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) > [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html src/java.base/share/classes/java/lang/invoke/CallSite.java line 88: > 86: */ > 87: public > 88: abstract class CallSite { I think it's better to move all modifiers to the single line. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From prappo at openjdk.java.net Tue Nov 2 19:25:14 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 2 Nov 2021 19:25:14 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 19:15:26 GMT, Andrey Turbanov wrote: >> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? >> >> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. >> >> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: >> >> $ sh ./bin/blessed-modifier-order.sh src/java.base >> >> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. >> >> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) >> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html > > src/java.base/share/classes/java/lang/invoke/CallSite.java line 88: > >> 86: */ >> 87: public >> 88: abstract class CallSite { > > I think it's better to move all modifiers to the single line. This is a survivorship bias. This example jumps out at you, because it happens to use missorted modifiers. I'm pretty sure this is not an aberration, but a style. If you want to change that style, you should create a respective JBS issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From mcimadamore at openjdk.java.net Tue Nov 2 18:52:21 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 2 Nov 2021 18:52:21 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:51:06 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak javadoc of loaderLookup > > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java line 88: > >> 86: if (size > arenaSize) { >> 87: throw new OutOfMemoryError(); >> 88: } > > Isn't this already covered by the `finally` block? Also, this seems to be checking the unaltered `size`, which I think should have been already done at the end of the previous `allocate` call right? I'll have to think some more about this. I don't think this is covered inside the block - that is, the block tries to allocate, and then in the finally we throw if we realized we've allocated too much. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Tue Nov 2 19:49:14 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 2 Nov 2021 19:49:14 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v13] In-Reply-To: References: Message-ID: <1DhHETKpULKzqGU-0EU7qcdSWDngTBO1UMQ39E8qzBw=.ad279b49-57fb-4026-9049-862b4aef2ada@github.com> > 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: - Address impl review comments - Address API review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/7cf4fcd9..1126133a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=11-12 Stats: 103 lines in 11 files changed: 8 ins; 23 del; 72 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 alanb at openjdk.java.net Tue Nov 2 19:49:15 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 2 Nov 2021 19:49:15 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v13] In-Reply-To: <1DhHETKpULKzqGU-0EU7qcdSWDngTBO1UMQ39E8qzBw=.ad279b49-57fb-4026-9049-862b4aef2ada@github.com> References: <1DhHETKpULKzqGU-0EU7qcdSWDngTBO1UMQ39E8qzBw=.ad279b49-57fb-4026-9049-862b4aef2ada@github.com> Message-ID: On Tue, 2 Nov 2021 19:35:29 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: > > - Address impl review comments > - Address API review comments src/java.base/share/classes/java/lang/Module.java line 114: > 112: > 113: // true, if this module allows restricted native access; @Stable makes sure that modules that allow native > 114: // access capture this property as a constant. Do you mind fixing this comment to avoid the really long line, it sticks out compare to everything else around it. src/java.base/share/classes/sun/nio/ch/IOUtil.java line 478: > 476: private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess(); > 477: > 478: static Runnable acquireScope(ByteBuffer bb, boolean async) { At some point (not this PR) we should move the "async" out of this file, IOUtil was for synchronous I/O. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Tue Nov 2 19:49:16 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 2 Nov 2021 19:49:16 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 18:55:47 GMT, Maurizio Cimadamore wrote: >> I'll have to think some more about this. I don't think this is covered inside the block - that is, the block tries to allocate, and then in the finally we throw if we realized we've allocated too much. > > What is missing, I think, is a check (size > arenaSize) at the beginning of the method (we only check this in one of the paths). But we need to check before and after, I think, as it is possible to allocate a segment and then realize that we ended up overflowing the arena size. While what I said above correctly reflects what the implementation does, I think a broader issue is that the arena allocator implementation is allocating sometimes more native memory than what its contract specifies. While in some cases we can prevent that, I think in the general case (e.g. where we allocate a new block) we cannot, unless we add extra API guarantees - e.g. that the arena size should be a multiple of the block size (but then we'd have to special case `Long.MAX_VALUE`, or maybe pick a "big enough" power of two instead) ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Tue Nov 2 19:49:16 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 2 Nov 2021 19:49:16 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 18:48:57 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java line 88: >> >>> 86: if (size > arenaSize) { >>> 87: throw new OutOfMemoryError(); >>> 88: } >> >> Isn't this already covered by the `finally` block? Also, this seems to be checking the unaltered `size`, which I think should have been already done at the end of the previous `allocate` call right? > > I'll have to think some more about this. I don't think this is covered inside the block - that is, the block tries to allocate, and then in the finally we throw if we realized we've allocated too much. What is missing, I think, is a check (size > arenaSize) at the beginning of the method (we only check this in one of the paths). But we need to check before and after, I think, as it is possible to allocate a segment and then realize that we ended up overflowing the arena size. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From jvernee at openjdk.java.net Tue Nov 2 19:49:16 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 2 Nov 2021 19:49:16 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 19:02:51 GMT, Maurizio Cimadamore wrote: >> What is missing, I think, is a check (size > arenaSize) at the beginning of the method (we only check this in one of the paths). But we need to check before and after, I think, as it is possible to allocate a segment and then realize that we ended up overflowing the arena size. > > While what I said above correctly reflects what the implementation does, I think a broader issue is that the arena allocator implementation is allocating sometimes more native memory than what its contract specifies. While in some cases we can prevent that, I think in the general case (e.g. where we allocate a new block) we cannot, unless we add extra API guarantees - e.g. that the arena size should be a multiple of the block size (but then we'd have to special case `Long.MAX_VALUE`, or maybe pick a "big enough" power of two instead) Maybe we should not support block size in the case of a bounded arena. i.e. just allocate the whole thing upfront, and have 3 APIs: 1. arena with no bounds and default block size. 2. arena with no bounds and custom block size. 3. arena with bounds, that has no blocks size but allocates the whole thing in one go (could be modeled as block size = arena size). Right now we have 1. and 2., but instead of 3. we have a variant that allows setting both the arena size and block size. If we want to keep what we currently have, I'd suggest changing the arena size to a block count for the variant that takes both the arena size and the block size (I think in that case `Long.MAX_VALUE` should still work?). Any ways, that seems like something that could be addressed in 19 as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From rriggs at openjdk.java.net Tue Nov 2 19:54:10 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 2 Nov 2021 19:54:10 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? > > As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. > > [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) > [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html Keep it as is with the modifiers in the recommended order. I don't think adding extra typography is warranted. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6213 From prappo at openjdk.java.net Tue Nov 2 19:59:14 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 2 Nov 2021 19:59:14 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 19:22:15 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/java/lang/invoke/CallSite.java line 88: >> >>> 86: */ >>> 87: public >>> 88: abstract class CallSite { >> >> I think it's better to move all modifiers to the single line. > > This is a survivorship bias. This example jumps out at you, because it happens to use missorted modifiers. I'm pretty sure this is not an aberration, but a style. If you want to change that style, you should create a respective JBS issue. I've grepped the code and can now see that a list of modifiers broken by newlines which cannot be explained by line-width concerns is indeed an irregularity. Not only in java.base but also in other modules. Although there aren't many of such cases, I would prefer them to be addressed in a separate cleanup, which you are welcome to pursue. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From martin at openjdk.java.net Tue Nov 2 20:38:21 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 2 Nov 2021 20:38:21 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? > > As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. > > [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) > [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html Marked as reviewed by martin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From martin at openjdk.java.net Tue Nov 2 20:38:21 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 2 Nov 2021 20:38:21 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com> Message-ID: On Tue, 2 Nov 2021 19:14:23 GMT, Pavel Rappo wrote: >> Pragmatically, fix the script to ignore those keywords on comment lines. >> Learn Perl, its just a regular expression pattern match and replace expression. >> >> All of the changes have to be manually reviewed by the author and then the reviewers. >> Checking unneeded changes is part of every mechanical change. >> >> The text being changed in the javadoc is the *spec*; that deserves special attention in review. >> >> But having seen several reviewers be unmoved by the difference, the real pragmatic view >> is to ignore the English. > >> Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression. > > I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted. > >> But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English. > > I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR. The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!) Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now. I don't have a strong feeling either way on changing that file. I agree with @pavelrappo that script-generated changes should not be mixed with manual changes. I would also not update copyright years for such changes. It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved. ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From mcimadamore at openjdk.java.net Tue Nov 2 21:33:46 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 2 Nov 2021 21:33:46 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v14] 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 long comment line in Module.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/1126133a..c219ae12 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=12-13 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 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 lancea at openjdk.java.net Tue Nov 2 22:41:28 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 2 Nov 2021 22:41:28 GMT Subject: RFR: 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error In-Reply-To: References: Message-ID: <12HctHnMgtVeY5bsMF_cIUseJAIVb8L31I6SaTNk9hs=.9bf8a28b-53b8-4215-90a3-140d55745029@github.com> On Tue, 2 Nov 2021 22:31:52 GMT, Brian Burkhalter wrote: > This request proposes to change the test to run in `othervm` mode. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6219 From bpb at openjdk.java.net Tue Nov 2 22:41:27 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 2 Nov 2021 22:41:27 GMT Subject: RFR: 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error Message-ID: This request proposes to change the test to run in `othervm` mode. ------------- Commit messages: - 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error Changes: https://git.openjdk.java.net/jdk/pull/6219/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6219&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276252 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6219.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6219/head:pull/6219 PR: https://git.openjdk.java.net/jdk/pull/6219 From bpb at openjdk.java.net Tue Nov 2 22:41:28 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 2 Nov 2021 22:41:28 GMT Subject: RFR: 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 22:31:52 GMT, Brian Burkhalter wrote: > This request proposes to change the test to run in `othervm` mode. The working assumption is that it failed in an agent VM running multiple tests which in the aggregate use up heap memory. ------------- PR: https://git.openjdk.java.net/jdk/pull/6219 From bpb at openjdk.java.net Tue Nov 2 23:37:44 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 2 Nov 2021 23:37:44 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v5] In-Reply-To: References: Message-ID: > 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: Change getNameCount() != 1 tp getParent() != null ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5594/files - new: https://git.openjdk.java.net/jdk/pull/5594/files/14f5a7aa..10949045 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5594&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5594&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5594/head:pull/5594 PR: https://git.openjdk.java.net/jdk/pull/5594 From jpai at openjdk.java.net Wed Nov 3 03:48:09 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 3 Nov 2021 03:48:09 GMT Subject: RFR: 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 22:31:52 GMT, Brian Burkhalter wrote: > This request proposes to change the test to run in `othervm` mode. test/jdk/java/nio/channels/Channels/TransferTo.java line 55: > 53: * @library /test/lib > 54: * @build jdk.test.lib.RandomFactory > 55: * @run testng/othervm TransferTo Hello Brian, should this also perhaps set the `-Xmx` value to a higher value or is the current VM defaults for max heap size on all VMs expected to be big enough for this test? ------------- PR: https://git.openjdk.java.net/jdk/pull/6219 From alanb at openjdk.java.net Wed Nov 3 07:24:12 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 3 Nov 2021 07:24:12 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v5] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 23:37:44 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: Change getNameCount() != 1 tp getParent() != null Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From alanb at openjdk.java.net Wed Nov 3 07:29:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 3 Nov 2021 07:29:08 GMT Subject: RFR: 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 03:44:56 GMT, Jaikiran Pai wrote: > Hello Brian, should this also perhaps set the `-Xmx` value to a higher value or is the current VM defaults for max heap size on all VMs expected to be big enough for this test? This may be helpful as this test needs to do some big transfer. For the specific OOME sighting then I suspect it may be more to do with how the tests are run. From what I can tell, it's running a very large group of tests and it's likely that the agent VM has been running for a long time. It could be that other tests that ran previously in this VM have left things behind. ------------- PR: https://git.openjdk.java.net/jdk/pull/6219 From prappo at openjdk.java.net Wed Nov 3 10:10:20 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 3 Nov 2021 10:10:20 GMT Subject: Integrated: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it en masse? > > As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. > > [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) > [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html This pull request has now been integrated. Changeset: 61506336 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/615063364ab6bdd3fa83401745e05b45e13eacdb Stats: 39 lines in 21 files changed: 0 ins; 0 del; 39 mod 8276348: Use blessed modifier order in java.base Reviewed-by: dfuchs, darcy, iris, rriggs, martin ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From prappo at openjdk.java.net Wed Nov 3 11:26:15 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 3 Nov 2021 11:26:15 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com> Message-ID: On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz wrote: >>> Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression. >> >> I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted. >> >>> But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English. >> >> I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR. > > The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!) > > Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now. > I don't have a strong feeling either way on changing that file. > > I agree with @pavelrappo that script-generated changes should not be mixed with manual changes. > I would also not update copyright years for such changes. > > It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved. One more thing. Please have a look at this other line in the same file; this line was there before the change https://github.com/openjdk/jdk/blob/465d350d0b3cac277a58b9f8ece196c1cde68e80/src/java.base/share/classes/java/lang/Object.java#L49 So before the change, the file was somewhat inconsistent. The change made it consistent. **If one is going to ever revert that controversial part of the change, please update both lines so that the file remains consistent.** ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From mcimadamore at openjdk.java.net Wed Nov 3 11:32:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 3 Nov 2021 11:32:50 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v15] In-Reply-To: References: Message-ID: <3l5SgC7qqzs4wj1leQ3TKp4gqDMXozx6W6bUxO1wlTA=.5db656f9-98d2-474a-918a-f076e63be127@github.com> > 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: Simplify ArenaAllocator impl. The arena should respect its boundaries and never allocate more memory than its size specifies. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/c219ae12..7f847271 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=13-14 Stats: 40 lines in 1 file changed: 8 ins; 15 del; 17 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 Nov 3 13:08:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 3 Nov 2021 13:08:55 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v16] 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: Make ArenaAllocator impl more flexible in the face of OOME An ArenaAllocator should remain open for business, even if OOME is thrown in case other allocations can fit the arena size. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/7f847271..9fafb2a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=14-15 Stats: 13 lines in 2 files changed: 3 ins; 6 del; 4 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 jvernee at openjdk.java.net Wed Nov 3 13:40:16 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 3 Nov 2021 13:40:16 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v16] In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 13:08:55 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: > > Make ArenaAllocator impl more flexible in the face of OOME > An ArenaAllocator should remain open for business, even if OOME is thrown in case other allocations can fit the arena size. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From prappo at openjdk.java.net Wed Nov 3 14:14:22 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 3 Nov 2021 14:14:22 GMT Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: References: Message-ID: <4kq1lfBwrSqekbOoZVlvgPROJLfb4SZKUHiySOBEwGs=.a4cb19d9-47da-49b8-8615-c34b3ae155b0@github.com> On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it en masse? > > As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. > > [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) > [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_ > > On 3/11/2021 9:26 pm, Pavel Rappo wrote: > > > On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz wrote: > > > > > Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression. > > > > > > > > > > > > I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted. > > > > > But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English. > > > > > > > > > > > > I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR. > > > > > > > > > The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!) > > > Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now. > > > I don't have a strong feeling either way on changing that file. > > > I agree with @pavelrappo that script-generated changes should not be mixed with manual changes. > > > I would also not update copyright years for such changes. > > > It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved. > > > > > > One more thing. Please have a look at this other line in the same file; this line was there before the change https://github.com/openjdk/jdk/blob/465d350d0b3cac277a58b9f8ece196c1cde68e80/src/java.base/share/classes/java/lang/Object.java#L49 > > So before the change, the file was somewhat inconsistent. The change made it consistent. **If one is going to ever revert that controversial part of the change, please update both lines so that the file remains consistent.** > > Line 281 is (was!) consistent with line 277 because it is distinguishing a synchronized "static method" from a synchronized "instance method". There was no need to make any change to line 281 because of the blessed-order of modifiers as defined for method declarations! This text is just prose. Now for consistency you should change line 277 to refer to a "non-static synchronized method" (as "instance synchronized method" would be truly awful). Thanks, David. You've provided a clear and convincing argument, and I can see the inconsistency I introduced. I can revert that particular piece back if you think that it would be appropriate. That said, this line will have to be filtered out every time the script is run. I could probably provide a more involved script that harnesses the power of AST (com.sun.source.doctree) to try to filter out prose, but it would be impossible to beat the simplicity of the current script; and simplicity is also important. > Line 49 places "static synchronized" in code font, implying that it is referring to the actual method modifiers and as such using the blessed order is appropriate. Line 49 does not need to be "consistent" with line 281. If line 49 used a normal font so the words "static" and "synchronized" were just prose then either order would be perfectly fine in terms of English language, but then you could make a case for having it be consistent with line 281. I've been always having hard time with modifiers being not enclosed in `@code` in the first place; they are barely English words. Is there really a semantic difference between L49 and L281 such that it warrants the use of `@code` in the former but not in the latter case? Does `synchornized` or `static` in L281 refer to anything other than the like-named Java modifiers? ------------- PR: https://git.openjdk.java.net/jdk/pull/6213 From dcubed at openjdk.java.net Wed Nov 3 15:00:33 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 3 Nov 2021 15:00:33 GMT Subject: RFR: 8276556: ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64 Message-ID: A trivial fix to ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64. ------------- Commit messages: - 8276556: ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64 Changes: https://git.openjdk.java.net/jdk/pull/6235/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6235&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276556 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6235.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6235/head:pull/6235 PR: https://git.openjdk.java.net/jdk/pull/6235 From alanb at openjdk.java.net Wed Nov 3 15:00:33 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 3 Nov 2021 15:00:33 GMT Subject: RFR: 8276556: ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64 In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 14:48:23 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6235 From dcubed at openjdk.java.net Wed Nov 3 15:06:14 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 3 Nov 2021 15:06:14 GMT Subject: RFR: 8276556: ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64 In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 14:54:53 GMT, Alan Bateman wrote: >> A trivial fix to ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64. > > Marked as reviewed by alanb (Reviewer). @AlanBateman - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/6235 From dcubed at openjdk.java.net Wed Nov 3 15:06:15 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 3 Nov 2021 15:06:15 GMT Subject: Integrated: 8276556: ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64 In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 14:48:23 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64. This pull request has now been integrated. Changeset: 87318460 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/87318460012d3fa1a8d3e8749d7a20328b27b826 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8276556: ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64 Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/6235 From bpb at openjdk.java.net Wed Nov 3 16:05:10 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 3 Nov 2021 16:05:10 GMT Subject: RFR: 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 07:26:10 GMT, Alan Bateman wrote: >> test/jdk/java/nio/channels/Channels/TransferTo.java line 55: >> >>> 53: * @library /test/lib >>> 54: * @build jdk.test.lib.RandomFactory >>> 55: * @run testng/othervm TransferTo >> >> Hello Brian, should this also perhaps set the `-Xmx` value to a higher value or is the current VM defaults for max heap size on all VMs expected to be big enough for this test? > >> Hello Brian, should this also perhaps set the `-Xmx` value to a higher value or is the current VM defaults for max heap size on all VMs expected to be big enough for this test? > > This may be helpful as this test needs to do some big transfer. For the specific OOME sighting then I suspect it may be more to do with how the tests are run. From what I can tell, it's running a very large group of tests and it's likely that the agent VM has been running for a long time. It could be that other tests that ran previously in this VM have left things behind. The version of the test proposed here passes with the command line option `-Xmx512M`, so if the default maximum heap size is really half the physical memory then I don't think it is necessary to set `-Xmx`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6219 From msheppar at openjdk.java.net Wed Nov 3 16:54:26 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Wed, 3 Nov 2021 16:54:26 GMT Subject: RFR: 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 16:01:43 GMT, Brian Burkhalter wrote: >>> Hello Brian, should this also perhaps set the `-Xmx` value to a higher value or is the current VM defaults for max heap size on all VMs expected to be big enough for this test? >> >> This may be helpful as this test needs to do some big transfer. For the specific OOME sighting then I suspect it may be more to do with how the tests are run. From what I can tell, it's running a very large group of tests and it's likely that the agent VM has been running for a long time. It could be that other tests that ran previously in this VM have left things behind. > > The version of the test proposed here passes with the command line option `-Xmx512M`, so if the default maximum heap size is really half the physical memory then I don't think it is necessary to set `-Xmx`. on the machine env where the failure has occurred we see that JVM has default heap size at 30GB and the machine has physical memory at 762GB ------------- PR: https://git.openjdk.java.net/jdk/pull/6219 From bpb at openjdk.java.net Wed Nov 3 16:54:26 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 3 Nov 2021 16:54:26 GMT Subject: RFR: 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 16:49:09 GMT, Mark Sheppard wrote: >> The version of the test proposed here passes with the command line option `-Xmx512M`, so if the default maximum heap size is really half the physical memory then I don't think it is necessary to set `-Xmx`. > > on the machine env where the failure has occurred we see that JVM has default heap size at 30GB and the machine has physical memory at 762GB So we would not expect an OOME for the test unless something else were gobbling up the heap memory. ------------- PR: https://git.openjdk.java.net/jdk/pull/6219 From bpb at openjdk.java.net Wed Nov 3 16:59:23 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 3 Nov 2021 16:59:23 GMT Subject: Integrated: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 02:19:03 GMT, Brian Burkhalter wrote: > Modify `sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsPath,String)` to handle file names which exceed the limit. This pull request has now been integrated. Changeset: 684edbb4 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/684edbb4c884cbc3e05118e4bc9808b5d5b71a74 Stats: 70 lines in 2 files changed: 55 ins; 0 del; 15 mod 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From msheppar at openjdk.java.net Wed Nov 3 17:37:10 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Wed, 3 Nov 2021 17:37:10 GMT Subject: RFR: 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error In-Reply-To: References: Message-ID: <5odg6MF7Y1kKjaK2-FCo5k1zk7kXIV0e8mEDkMGPACo=.376ae2da-539d-4338-ac2a-b6b19c4341e5@github.com> On Wed, 3 Nov 2021 16:51:34 GMT, Brian Burkhalter wrote: >> on the machine env where the failure has occurred we see that JVM has default heap size at 30GB and the machine has physical memory at 762GB > > So we would not expect an OOME for the test unless something else were gobbling up the heap memory. I've just checked the jtreg parameters for vm options and the -Xmx512M is set for the test also sets a I've just checked and the test is not run with default option, but with explicit setting of 512MB a MAX_RAM_PERCENTAGE option -vmoption:-XX:MaxRAMPercentage=$MAX_RAM_PERCENTAGE MAX_RAM_PERCENTAGE == 25/18 which rounds up to 1 ------------- PR: https://git.openjdk.java.net/jdk/pull/6219 From mcimadamore at openjdk.java.net Wed Nov 3 17:40:56 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 3 Nov 2021 17:40:56 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v17] 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 TestUpcall * reverse() has a bug, as it doesn't tweak parameter types * reverse() is applied to the wrong MH ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/9fafb2a6..b9432473 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=15-16 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 duke at openjdk.java.net Wed Nov 3 18:51:16 2021 From: duke at openjdk.java.net (Mike Hearn) Date: Wed, 3 Nov 2021 18:51:16 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v5] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 23:37:44 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: Change getNameCount() != 1 tp getParent() != null @bplb Unfortunately this doesn't work for me and actually, yields a regression. After trying the patch I now get this error: Caused by: java.lang.AssertionError: Illegal character [?] in path at index 2: \?\C:\BuildAgent\work\88d980e906e2ca5f\modules\hydraulic.parts.testing\build\tests\parts\cache\entries\4b\4f\4b4f0c6a0f0d079b\content\Hello World.app\Contents\Frameworks\Sparkle.framework\Versions\A\Resources\Base.lproj\SUUpdatePermissionPrompt.nib\keyedobjects-110000.nib:posixmode at java.base/sun.nio.fs.WindowsPath.createFromNormalizedPath(WindowsPath.java:119) at java.base/sun.nio.fs.WindowsPath.createFromNormalizedPath(WindowsPath.java:129) at java.base/sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsUserDefinedFileAttributeView.java:65) at java.base/sun.nio.fs.WindowsUserDefinedFileAttributeView.write(WindowsUserDefinedFileAttributeView.java:215) The stack trace is truncated because AssertionError is rethrown without a cause, but the problem seems to be coming from the `nextSlash` method. Basically, now the `\?` prefixed path is being passed to `createFromNormalizedPath` but it's not expecting that - the code (eventually) tries to scan past slashes and is unhappy because ? is not a valid character for a Windows path, except when it's in the magic prefix. I don't know why the unit test doesn't pick up on this problem or how exactly the code gets to that position. As you can see, the path it's trying to set an EA on here is very long indeed. Perhaps this is a pre-existing bug in WindowsPath.java exposed by the change? I'm not sure which version you mean sorry. Version 2 of this PR? Which commit does that correspond to? I can try it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From bpb at openjdk.java.net Wed Nov 3 18:51:17 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 3 Nov 2021 18:51:17 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v5] In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 18:40:43 GMT, Mike Hearn wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273922: Change getNameCount() != 1 tp getParent() != null > > @bplb Unfortunately this doesn't work for me and actually, yields a regression. After trying the patch I now get this error: > > > Caused by: java.lang.AssertionError: Illegal character [?] in path at index 2: \?\C:\BuildAgent\work\88d980e906e2ca5f\modules\hydraulic.parts.testing\build\tests\parts\cache\entries\4b\4f\4b4f0c6a0f0d079b\content\Hello World.app\Contents\Frameworks\Sparkle.framework\Versions\A\Resources\Base.lproj\SUUpdatePermissionPrompt.nib\keyedobjects-110000.nib:posixmode > at java.base/sun.nio.fs.WindowsPath.createFromNormalizedPath(WindowsPath.java:119) > at java.base/sun.nio.fs.WindowsPath.createFromNormalizedPath(WindowsPath.java:129) > at java.base/sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsUserDefinedFileAttributeView.java:65) > at java.base/sun.nio.fs.WindowsUserDefinedFileAttributeView.write(WindowsUserDefinedFileAttributeView.java:215) > > > The stack trace is truncated because AssertionError is rethrown without a cause, but the problem seems to be coming from the `nextSlash` method. Basically, now the `\?` prefixed path is being passed to `createFromNormalizedPath` but it's not expecting that - the code (eventually) tries to scan past slashes and is unhappy because ? is not a valid character for a Windows path, except when it's in the magic prefix. > > I don't know why the unit test doesn't pick up on this problem or how exactly the code gets to that position. As you can see, the path it's trying to set an EA on here is very long indeed. Perhaps this is a pre-existing bug in WindowsPath.java exposed by the change? @mikehearn Did any of the previous versions work for you, e.g., version 02? ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From bpb at openjdk.java.net Wed Nov 3 18:51:17 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 3 Nov 2021 18:51:17 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v5] In-Reply-To: References: Message-ID: <8ZmwxROZTxe0QOB0umC5CfYN2g_zP5gYOCeRXeBa88c=.98e8288f-0c29-49b0-a620-4877f6995ef3@github.com> On Tue, 2 Nov 2021 23:37:44 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: Change getNameCount() != 1 tp getParent() != null That would be the third commit, labelled 02 (zero-relative). ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From alanb at openjdk.java.net Wed Nov 3 18:57:21 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 3 Nov 2021 18:57:21 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v5] In-Reply-To: <8ZmwxROZTxe0QOB0umC5CfYN2g_zP5gYOCeRXeBa88c=.98e8288f-0c29-49b0-a620-4877f6995ef3@github.com> References: <8ZmwxROZTxe0QOB0umC5CfYN2g_zP5gYOCeRXeBa88c=.98e8288f-0c29-49b0-a620-4877f6995ef3@github.com> Message-ID: On Wed, 3 Nov 2021 18:46:48 GMT, Brian Burkhalter wrote: > That would be the third commit, labelled 02 (zero-relative). In Mike's example it looks like it's a long path. ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From bpb at openjdk.java.net Wed Nov 3 19:18:27 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 3 Nov 2021 19:18:27 GMT Subject: RFR: 8276199: java/nio/channels/FileChannel/LargeGatheringWrite.java fails to terminate correctly Message-ID: Double the test timeout and remove the test from the ProblemList. ------------- Commit messages: - 8276199: java/nio/channels/FileChannel/LargeGatheringWrite.java fails to terminate correctly Changes: https://git.openjdk.java.net/jdk/pull/6238/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6238&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276199 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6238.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6238/head:pull/6238 PR: https://git.openjdk.java.net/jdk/pull/6238 From bpb at openjdk.java.net Wed Nov 3 19:18:28 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 3 Nov 2021 19:18:28 GMT Subject: RFR: 8276199: java/nio/channels/FileChannel/LargeGatheringWrite.java fails to terminate correctly In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 19:04:52 GMT, Brian Burkhalter wrote: > Double the test timeout and remove the test from the ProblemList. The test appears to require about 80s-90s in the CI of which approximately 90% is from the beginning until just after the gathering write. A repeat of 100 tests with the default timeout (480s) showed no failures. Other runs with 10 repeats for 84s, 120s, and 240s showed no failures. ------------- PR: https://git.openjdk.java.net/jdk/pull/6238 From david.holmes at oracle.com Thu Nov 4 03:09:34 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Nov 2021 13:09:34 +1000 Subject: RFR: 8276348: Use blessed modifier order in java.base In-Reply-To: <4kq1lfBwrSqekbOoZVlvgPROJLfb4SZKUHiySOBEwGs=.a4cb19d9-47da-49b8-8615-c34b3ae155b0@github.com> References: <4kq1lfBwrSqekbOoZVlvgPROJLfb4SZKUHiySOBEwGs=.a4cb19d9-47da-49b8-8615-c34b3ae155b0@github.com> Message-ID: <531451b4-b966-e2cb-91ca-52a825c84ad9@oracle.com> On 4/11/2021 12:14 am, Pavel Rappo wrote: > On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > >> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it en masse? >> >> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them. >> >> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary: >> >> $ sh ./bin/blessed-modifier-order.sh src/java.base >> >> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files. >> >> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365) >> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_ >> >> On 3/11/2021 9:26 pm, Pavel Rappo wrote: >> >>> On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz wrote: >>>>>> Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression. >>>>> >>>>> >>>>> I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted. >>>>>> But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English. >>>>> >>>>> >>>>> I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR. >>>> >>>> >>>> The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!) >>>> Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now. >>>> I don't have a strong feeling either way on changing that file. >>>> I agree with @pavelrappo that script-generated changes should not be mixed with manual changes. >>>> I would also not update copyright years for such changes. >>>> It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved. >>> >>> >>> One more thing. Please have a look at this other line in the same file; this line was there before the change https://github.com/openjdk/jdk/blob/465d350d0b3cac277a58b9f8ece196c1cde68e80/src/java.base/share/classes/java/lang/Object.java#L49 >>> So before the change, the file was somewhat inconsistent. The change made it consistent. **If one is going to ever revert that controversial part of the change, please update both lines so that the file remains consistent.** >> >> Line 281 is (was!) consistent with line 277 because it is distinguishing a synchronized "static method" from a synchronized "instance method". There was no need to make any change to line 281 because of the blessed-order of modifiers as defined for method declarations! This text is just prose. Now for consistency you should change line 277 to refer to a "non-static synchronized method" (as "instance synchronized method" would be truly awful). > > Thanks, David. You've provided a clear and convincing argument, and I can see the inconsistency I introduced. I can revert that particular piece back if you think that it would be appropriate. > > That said, this line will have to be filtered out every time the script is run. I could probably provide a more involved script that harnesses the power of AST (com.sun.source.doctree) to try to filter out prose, but it would be impossible to beat the simplicity of the current script; and simplicity is also important. Given this is prose, the adjectives should be separated by commas: "a synchronized, static method", and "a synchronized, instance method". Does that avoid the problem with the script? >> Line 49 places "static synchronized" in code font, implying that it is referring to the actual method modifiers and as such using the blessed order is appropriate. Line 49 does not need to be "consistent" with line 281. If line 49 used a normal font so the words "static" and "synchronized" were just prose then either order would be perfectly fine in terms of English language, but then you could make a case for having it be consistent with line 281. > > I've been always having hard time with modifiers being not enclosed in `@code` in the first place; they are barely English words. Is there really a semantic difference between L49 and L281 such that it warrants the use of `@code` in the former but not in the latter case? Does `synchornized` or `static` in L281 refer to anything other than the like-named Java modifiers? Consider this definition: "A synchronized method is one which must acquire the monitor of the Object upon which the method is invoked, and is indicated by applying the {@code synchronized} modifier to the method declaration." Here there is a distinction** between the general notion of a "synchronized method" and the "synchronized" modifier. Obviously they are strongly related, and often could be used interchangeably, but you can also find places where it is more appropriate to use one over the other. So yes it is hard, but context can influence the choice: is this text referring to the general concept of a synchronized/static method, or to the use of the modifier? Line 49 could have gone either way IMO. ** The distinction would be more obvious if Java had an implicit way to define synchronized methods. So think about the concept of "package private" access - there is no package-private modifier so you wouldn't/shouldn't ever write "package private" in code font. Cheers, David P.S. For the book "The Java Programming Language" the authors made a very conscious decision to not put the word "synchronized" in code font every time it was used in the text, but reserved the code font for specific usages. The same applies to other modifiers: static, public, etc. Other authors have made similar decisions. > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/6213 > From alanb at openjdk.java.net Thu Nov 4 07:46:18 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 4 Nov 2021 07:46:18 GMT Subject: RFR: 8276199: java/nio/channels/FileChannel/LargeGatheringWrite.java fails to terminate correctly In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 19:04:52 GMT, Brian Burkhalter wrote: > Double the test timeout and remove the test from the ProblemList. We need to monitor it but okay for now. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6238 From pconcannon at openjdk.java.net Thu Nov 4 11:51:39 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 4 Nov 2021 11:51:39 GMT Subject: RFR: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java Message-ID: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> Hi, Could someone please review my changes for removing `usePlainDatagramSocketImpl` options from the test DatagramChannel/SendReceiveMaxSize.java? The option `usePlainDatagramSocketImpl` was not removed during [JDK-8253119 - Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation](https://bugs.openjdk.java.net/browse/JDK-8253119). As these implementations have now been removed from the JDK, tests no longer need to check against it. The test `test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` as well as `test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java` still have this option as its removal was overlooked in the original issue. It can now be removed from both tests. Kind regards, Patrick ------------- Commit messages: - 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java Changes: https://git.openjdk.java.net/jdk/pull/6252/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6252&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276634 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6252.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6252/head:pull/6252 PR: https://git.openjdk.java.net/jdk/pull/6252 From dfuchs at openjdk.java.net Thu Nov 4 11:51:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 4 Nov 2021 11:51:40 GMT Subject: RFR: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java In-Reply-To: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> References: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> Message-ID: On Thu, 4 Nov 2021 11:39:15 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changes for removing `usePlainDatagramSocketImpl` options from the test DatagramChannel/SendReceiveMaxSize.java? > > The option `usePlainDatagramSocketImpl` was not removed during [JDK-8253119 - Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation](https://bugs.openjdk.java.net/browse/JDK-8253119). As these implementations have now been removed from the JDK, tests no longer need to check against it. > > The test `test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` as well as `test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java` still have this option as its removal was overlooked in the original issue. It can now be removed from both tests. > > > Kind regards, > Patrick Thanks for the cleanup Patrick! ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6252 From msheppar at openjdk.java.net Thu Nov 4 12:31:14 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Thu, 4 Nov 2021 12:31:14 GMT Subject: RFR: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java In-Reply-To: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> References: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> Message-ID: On Thu, 4 Nov 2021 11:39:15 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changes for removing `usePlainDatagramSocketImpl` options from the test DatagramChannel/SendReceiveMaxSize.java? > > The option `usePlainDatagramSocketImpl` was not removed during [JDK-8253119 - Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation](https://bugs.openjdk.java.net/browse/JDK-8253119). As these implementations have now been removed from the JDK, tests no longer need to check against it. > > The test `test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` as well as `test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java` still have this option as its removal was overlooked in the original issue. It can now be removed from both tests. > > > Kind regards, > Patrick has the property been retained? If it still exists, then it would seem that the test scenarios are still valid. ------------- PR: https://git.openjdk.java.net/jdk/pull/6252 From alanb at openjdk.java.net Thu Nov 4 12:42:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 4 Nov 2021 12:42:09 GMT Subject: RFR: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java In-Reply-To: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> References: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> Message-ID: On Thu, 4 Nov 2021 11:39:15 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changes for removing `usePlainDatagramSocketImpl` options from the test DatagramChannel/SendReceiveMaxSize.java? > > The option `usePlainDatagramSocketImpl` was not removed during [JDK-8253119 - Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation](https://bugs.openjdk.java.net/browse/JDK-8253119). As these implementations have now been removed from the JDK, tests no longer need to check against it. > > The test `test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` as well as `test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java` still have this option as its removal was overlooked in the original issue. It can now be removed from both tests. > > > Kind regards, > Patrick Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6252 From pconcannon at openjdk.java.net Thu Nov 4 14:56:09 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 4 Nov 2021 14:56:09 GMT Subject: RFR: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java In-Reply-To: References: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> Message-ID: On Thu, 4 Nov 2021 12:28:01 GMT, Mark Sheppard wrote: > has the property been retained? If it still exists, then it would seem that the test scenarios are still valid. No, the property, along with the implementation it referred to, was removed in JDK-8253119. More details can be found in the related CSR: https://bugs.openjdk.java.net/browse/JDK-8269759 ------------- PR: https://git.openjdk.java.net/jdk/pull/6252 From dfuchs at openjdk.java.net Thu Nov 4 15:02:13 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 4 Nov 2021 15:02:13 GMT Subject: RFR: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java In-Reply-To: References: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> Message-ID: <1mVqIVeKlkyWc1nWH8q4RpmYfLy-y8ki94ttjCDOhN4=.de628162-c9c6-4659-9001-b683ae9b81a0@github.com> On Thu, 4 Nov 2021 14:53:18 GMT, Patrick Concannon wrote: > has the property been retained? If it still exists, then it would seem that the test scenarios are still valid. $ find src/java.base/ -type f | xargs grep usePlainDatagramSocketImpl | wc -l 0 There's nothing in the code that reads or depends on that property. So retaining it in test doesn't make much sense IMO. In addition though `test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java` uses a mix of `DatagramSocket` and `DatagramChannel`, `test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` only uses `DatagramChannel` which never depended on that property in the first place, so having additional `@run` in there was probably a copy-paste mistake. ------------- PR: https://git.openjdk.java.net/jdk/pull/6252 From msheppar at openjdk.java.net Thu Nov 4 15:21:11 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Thu, 4 Nov 2021 15:21:11 GMT Subject: RFR: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java In-Reply-To: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> References: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> Message-ID: On Thu, 4 Nov 2021 11:39:15 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changes for removing the `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java? > > The option `usePlainDatagramSocketImpl` was not removed during [JDK-8253119 - Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation](https://bugs.openjdk.java.net/browse/JDK-8253119). As these implementations have now been removed from the JDK, tests no longer need to check against it. > > The test `test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` as well as `test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java` still have this option as its removal was overlooked in the original issue. It can now be removed from both tests. > > > Kind regards, > Patrick yes, thanks for the clarification Daniel I hadn't read the release note but, the release note says Support for the system properties `jdk.net.usePlainSocketImpl` and `jdk.net.usePlainDatagramSocketImpl`, used to select these implementations, has also been removed. Setting these properties will now have no effect. So that the fact that the test's have unintentionally remained, actually validates the release note although arguable there has been a side effect, i.e. test failure not observed previously -- but that could be coincidental even though these are DatagramChannel test, DatagramChannel does encapsulate (or contains) a DatagramSocket, so may not be altogether irrelevant ? ------------- PR: https://git.openjdk.java.net/jdk/pull/6252 From bpb at openjdk.java.net Thu Nov 4 16:36:14 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 4 Nov 2021 16:36:14 GMT Subject: Integrated: 8276199: java/nio/channels/FileChannel/LargeGatheringWrite.java fails to terminate correctly In-Reply-To: References: Message-ID: <8Dc7D-W6FC8b7AIW5_hJInPfHkWH0dayT1VDHj6j3Wk=.638859e2-fa9b-4438-a3c3-48334795aae2@github.com> On Wed, 3 Nov 2021 19:04:52 GMT, Brian Burkhalter wrote: > Double the test timeout and remove the test from the ProblemList. This pull request has now been integrated. Changeset: 7bb21733 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/7bb2173383bc1c0d55564d31303a547957d87a15 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod 8276199: java/nio/channels/FileChannel/LargeGatheringWrite.java fails to terminate correctly Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/6238 From dfuchs at openjdk.java.net Thu Nov 4 19:28:08 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 4 Nov 2021 19:28:08 GMT Subject: RFR: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java In-Reply-To: References: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> Message-ID: On Thu, 4 Nov 2021 15:18:17 GMT, Mark Sheppard wrote: > even though these are DatagramChannel test, DatagramChannel does encapsulate (or contains) a DatagramSocket, so may not be altogether irrelevant ? No it's the other way round `DatagramSocket` encapsulates a `DatagramChannel`. The property was here to allow `DatagramSocket` to not encapsulate a `DatagramChannel` by default but revert to using the legacy `DatagramSocketImpl` implementation built in the JDK. And that impl has now been removed. So the property never had any effect on the `DatagramChannel` implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/6252 From msheppar at openjdk.java.net Thu Nov 4 19:44:14 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Thu, 4 Nov 2021 19:44:14 GMT Subject: RFR: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java In-Reply-To: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> References: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> Message-ID: <58mIy_7RxBleHBpfs1UebOYJ9_NS5hz8OTSlE9B2yYk=.d9612dc4-793c-407c-b417-bfde5cdea6f2@github.com> On Thu, 4 Nov 2021 11:39:15 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changes for removing the `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java? > > The option `usePlainDatagramSocketImpl` was not removed during [JDK-8253119 - Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation](https://bugs.openjdk.java.net/browse/JDK-8253119). As these implementations have now been removed from the JDK, tests no longer need to check against it. > > The test `test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` as well as `test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java` still have this option as its removal was overlooked in the original issue. It can now be removed from both tests. > > > Kind regards, > Patrick We might end up talking at cross purposes here!! But, it is worth noting that DatagramChannel::socket returns a DatagramSocket and so DatagramChannel encapsulates a DatagramSocket. As such you'd anticipate that the property would have some influence over the DatagramSocket and its implementation. As of now the property is redundant, but the operational semantics should be the same as previously existed when the property was valid. I understand your perspective, that with the updated restructuring of the DatagramSocket implementation and it delegation into DatagramChannel implementation there is a form of DatagramChannel implementation encapsulation. ------------- PR: https://git.openjdk.java.net/jdk/pull/6252 From dfuchs at openjdk.java.net Thu Nov 4 20:35:12 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 4 Nov 2021 20:35:12 GMT Subject: RFR: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java In-Reply-To: <58mIy_7RxBleHBpfs1UebOYJ9_NS5hz8OTSlE9B2yYk=.d9612dc4-793c-407c-b417-bfde5cdea6f2@github.com> References: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> <58mIy_7RxBleHBpfs1UebOYJ9_NS5hz8OTSlE9B2yYk=.d9612dc4-793c-407c-b417-bfde5cdea6f2@github.com> Message-ID: On Thu, 4 Nov 2021 19:41:39 GMT, Mark Sheppard wrote: > As such you'd anticipate that the property would have some influence over the DatagramSocket and its implementation Well... No. That was never the case. ------------- PR: https://git.openjdk.java.net/jdk/pull/6252 From vtewari at openjdk.java.net Fri Nov 5 05:08:11 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Fri, 5 Nov 2021 05:08:11 GMT Subject: RFR: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java In-Reply-To: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> References: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> Message-ID: On Thu, 4 Nov 2021 11:39:15 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changes for removing the `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java? > > The option `usePlainDatagramSocketImpl` was not removed during [JDK-8253119 - Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation](https://bugs.openjdk.java.net/browse/JDK-8253119). As these implementations have now been removed from the JDK, tests no longer need to check against it. > > The test `test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` as well as `test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java` still have this option as its removal was overlooked in the original issue. It can now be removed from both tests. > > > Kind regards, > Patrick Marked as reviewed by vtewari (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6252 From pconcannon at openjdk.java.net Fri Nov 5 10:44:17 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 5 Nov 2021 10:44:17 GMT Subject: Integrated: 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java In-Reply-To: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> References: <4x9kUnlt41soYV-74Z-4mB4gyGg16c-4ejA1W_lwgak=.34a185fa-2187-4642-b8b6-e85d7509a6ce@github.com> Message-ID: On Thu, 4 Nov 2021 11:39:15 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changes for removing the `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java? > > The option `usePlainDatagramSocketImpl` was not removed during [JDK-8253119 - Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation](https://bugs.openjdk.java.net/browse/JDK-8253119). As these implementations have now been removed from the JDK, tests no longer need to check against it. > > The test `test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` as well as `test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java` still have this option as its removal was overlooked in the original issue. It can now be removed from both tests. > > > Kind regards, > Patrick This pull request has now been integrated. Changeset: d95299a4 Author: Patrick Concannon URL: https://git.openjdk.java.net/jdk/commit/d95299a4d751449816ad2a88359f1e48e9608246 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java Reviewed-by: dfuchs, alanb, vtewari ------------- PR: https://git.openjdk.java.net/jdk/pull/6252 From mcimadamore at openjdk.java.net Fri Nov 5 11:06:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 5 Nov 2021 11:06:53 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v18] In-Reply-To: References: Message-ID: <4iHYQMJoHZwfRJCHV9tYB_5t92pjEsgISw_d9_Nt6H8=.1fb75c40-a6ee-498a-9d4e-cf1b6d11b583@github.com> > 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: * Add two new CLinker static methods to compute upcall/downcall method types * Clarify section on CLinker downcall type * Add section on CLinker safety guarantees ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/b9432473..ce561e1f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=16-17 Stats: 79 lines in 3 files changed: 47 ins; 17 del; 15 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 Nov 5 11:30:59 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 5 Nov 2021 11:30:59 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v19] 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: Streamline javadoc for package-info ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/ce561e1f..350f1f07 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=17-18 Stats: 37 lines in 1 file changed: 9 ins; 3 del; 25 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 Nov 5 11:37:57 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 5 Nov 2021 11:37:57 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v20] In-Reply-To: References: Message-ID: <1EDavlhSqnzIbpu1uQArxPknmjIMaeQEoPV8W1T3UjE=.9a5dcd88-0cc7-4965-b2b7-3cccaf70b50e@github.com> > 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: Rename MemorySegment::ofAddressNative to MemorySegment::ofAddress (which is consistent with other restricted factories in VaList and NativeSymbol) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/350f1f07..663e72a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=18-19 Stats: 51 lines in 23 files changed: 0 ins; 3 del; 48 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 Nov 5 11:54:14 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 5 Nov 2021 11:54:14 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 15:40:45 GMT, Paul Sandoz wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak javadoc of loaderLookup > > Marked as reviewed by psandoz (Reviewer). I have made some minor API changes (added two methods to `CLinker` to return the upcall and downcall method types, as suggested offline by @PaulSandoz). I've also cleaned up the `CLinker` javadoc, and added a section on safety consideration, streamlined the links in the package-level javadoc and renamed `MemorySegment::ofAddressNative` to simply `MemorySegment::ofAddress` (which is consistent with restricted factories in `NativeSymbol` and `VaList`). javadoc: http://cr.openjdk.java.net/~mcimadamore/JEP-419/v2/javadoc/jdk/incubator/foreign/package-summary.html specdiff: http://cr.openjdk.java.net/~mcimadamore/JEP-419/v2/specdiff_out/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From jvernee at openjdk.java.net Fri Nov 5 14:29:19 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 5 Nov 2021 14:29:19 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v18] In-Reply-To: <4iHYQMJoHZwfRJCHV9tYB_5t92pjEsgISw_d9_Nt6H8=.1fb75c40-a6ee-498a-9d4e-cf1b6d11b583@github.com> References: <4iHYQMJoHZwfRJCHV9tYB_5t92pjEsgISw_d9_Nt6H8=.1fb75c40-a6ee-498a-9d4e-cf1b6d11b583@github.com> Message-ID: On Fri, 5 Nov 2021 11:06:53 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: > > * Add two new CLinker static methods to compute upcall/downcall method types > * Clarify section on CLinker downcall type > * Add section on CLinker safety guarantees src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 65: > 63: *
  • if {@code L} is a {@link ValueLayout} with carrier {@code E} then there are two cases: > 64: *
      > 65: *
    • if {@code L} occurs in a parameter position and {@code E} is {@code NativeAddress.class}, This looks spurious src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 134: > 132: *

      > 133: * Upcall stubs are generally safer to work with, as the linker runtime can validate the type of the target method > 134: * handle against the provided function descriptor and report an error if any mismatch is detected. If the target method But, in the case of upcalls, errors can still occur if the native code casts the pointer to the upcall stub to an incorrect type, e.g. `FunctionDescriptor.ofVoid(ADDRESS, ADDRESS)`, but on the native side cast it to `void (*)(void*)`, meaning the second argument would be garbage on the Java side. i.e. there is still room for a mismatch the same as with downcalls. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 267: > 265: static MethodType upcallType(FunctionDescriptor functionDescriptor) { > 266: return SharedUtils.inferMethodType(functionDescriptor, true); > 267: } Nice! :) ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Fri Nov 5 14:37:23 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 5 Nov 2021 14:37:23 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v18] In-Reply-To: References: <4iHYQMJoHZwfRJCHV9tYB_5t92pjEsgISw_d9_Nt6H8=.1fb75c40-a6ee-498a-9d4e-cf1b6d11b583@github.com> Message-ID: On Fri, 5 Nov 2021 14:25:35 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> * Add two new CLinker static methods to compute upcall/downcall method types >> * Clarify section on CLinker downcall type >> * Add section on CLinker safety guarantees > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 134: > >> 132: *

      >> 133: * Upcall stubs are generally safer to work with, as the linker runtime can validate the type of the target method >> 134: * handle against the provided function descriptor and report an error if any mismatch is detected. If the target method > > But, in the case of upcalls, errors can still occur if the native code casts the pointer to the upcall stub to an incorrect type, e.g. `FunctionDescriptor.ofVoid(ADDRESS, ADDRESS)`, but on the native side cast it to `void (*)(void*)`, meaning the second argument would be garbage on the Java side. i.e. there is still room for a mismatch the same as with downcalls. Yes and no. In a downcall, you just don't know what signature the downcall will feature in the native lib. So you pass a function descriptor and you hope it's ok. In the upcall case you _do_ know the signature of the Java upcall code you want to call, so you can validate the descriptor against that. Of course the native code can still cast things around in ways that blow things up, but the two problems seem somewhat different, at least to me. But I can tweak the text a bit. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Fri Nov 5 15:28:45 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 5 Nov 2021 15:28:45 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v21] In-Reply-To: References: Message-ID: <_YLlQk23TfRkCzouXvgHH3Zxktw1sxo1uvae5KsjlFw=.3c4f3aeb-e24f-424b-94f4-04b19f0e834b@github.com> > 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: Clarify safety considerations for upcalls ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/663e72a8..2aa126a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=19-20 Stats: 5 lines in 1 file changed: 2 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 jvernee at openjdk.java.net Fri Nov 5 15:52:16 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 5 Nov 2021 15:52:16 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v18] In-Reply-To: References: <4iHYQMJoHZwfRJCHV9tYB_5t92pjEsgISw_d9_Nt6H8=.1fb75c40-a6ee-498a-9d4e-cf1b6d11b583@github.com> Message-ID: On Fri, 5 Nov 2021 14:33:44 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 134: >> >>> 132: *

      >>> 133: * Upcall stubs are generally safer to work with, as the linker runtime can validate the type of the target method >>> 134: * handle against the provided function descriptor and report an error if any mismatch is detected. If the target method >> >> But, in the case of upcalls, errors can still occur if the native code casts the pointer to the upcall stub to an incorrect type, e.g. `FunctionDescriptor.ofVoid(ADDRESS, ADDRESS)`, but on the native side cast it to `void (*)(void*)`, meaning the second argument would be garbage on the Java side. i.e. there is still room for a mismatch the same as with downcalls. > > Yes and no. In a downcall, you just don't know what signature the downcall will feature in the native lib. So you pass a function descriptor and you hope it's ok. In the upcall case you _do_ know the signature of the Java upcall code you want to call, so you can validate the descriptor against that. Of course the native code can still cast things around in ways that blow things up, but the two problems seem somewhat different, at least to me. But I can tweak the text a bit. Ok, thanks. I think of it more like this: in both cases we specify a native type as well as a Java type, both in the form of a FunctionDescriptor, from which we then derive the Java type in the form of a MethodType. If there is a mismatch here with what the native code does we are in trouble, this seems the same for downcalls and upcalls. In both cases we know the Java side for sure, it's the native side we can't validate (they are just flipped around for upcalls). But, for upcalls there is an additional thing that can go wrong: the type of the target MethodHandle we pass could have a mismatch with the type we inferred from the FunctionDescriptor, so there we need to do an extra check. i.e. in a way this seems _less_ safe (though a different kind of safety), than downcalls, since there is an additional way to mess up with the linkage request, although we can catch that case. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Fri Nov 5 16:02:43 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 5 Nov 2021 16:02:43 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v22] 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: Further tweak upcall safety considerations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/2aa126a9..4e3af9f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=20-21 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 bpb at openjdk.java.net Fri Nov 5 17:28:13 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 5 Nov 2021 17:28:13 GMT Subject: Integrated: 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 22:31:52 GMT, Brian Burkhalter wrote: > This request proposes to change the test to run in `othervm` mode. This pull request has now been integrated. Changeset: b01f1073 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/b01f1073f9691c40fc15b7ed67ae2e019ff729ea Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/6219 From naoto at openjdk.java.net Fri Nov 5 17:55:44 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 5 Nov 2021 17:55:44 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales Message-ID: Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. ------------- Commit messages: - Use UTF-8 if jnuEncoding is not supported - Utilized 2-arg Charset.forName() - 8275007: Java fails to start with null charset if LC_ALL is set to certain Changes: https://git.openjdk.java.net/jdk/pull/6282/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275007 Stats: 22 lines in 3 files changed: 4 ins; 7 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/6282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6282/head:pull/6282 PR: https://git.openjdk.java.net/jdk/pull/6282 From rriggs at openjdk.java.net Fri Nov 5 19:51:37 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 5 Nov 2021 19:51:37 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 17:31:50 GMT, Naoto Sato wrote: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From joehw at openjdk.java.net Fri Nov 5 20:13:40 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 5 Nov 2021 20:13:40 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 17:31:50 GMT, Naoto Sato wrote: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. Do you need to add test? ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6282 From iris at openjdk.java.net Fri Nov 5 20:13:40 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 5 Nov 2021 20:13:40 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: <0ekS47ocP6oHUJ3TkicRLSF2rcz4wIUj366gVNCZPKM=.a1f9371d-6ca3-4f65-8237-6fd12a6a6039@github.com> On Fri, 5 Nov 2021 17:31:50 GMT, Naoto Sato wrote: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From naoto at openjdk.java.net Fri Nov 5 20:24:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 5 Nov 2021 20:24:37 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 20:10:28 GMT, Joe Wang wrote: > Do you need to add test? I would if I could, but specifying the environment dependent settings in the test would be fragile and error-prone, so I did not add a test but marked the issue as `noreg-hard`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Fri Nov 5 20:37:37 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 5 Nov 2021 20:37:37 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 17:31:50 GMT, Naoto Sato wrote: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From duke at openjdk.java.net Sat Nov 6 08:13:34 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 6 Nov 2021 08:13:34 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, I am currently working on its final solution. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sat Nov 6 15:16:52 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 6 Nov 2021 15:16:52 GMT Subject: RFR: 8276779: ChannelInputStream.transferTo() uses FileChannel.transferTo(WritableByteChannel) [v11] In-Reply-To: References: Message-ID: > 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). > > **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo() This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferTo(WritableByteChannel), including special treatment of SelectableByteChannel. Signed-off-by: Markus Karg ------------- Changes: https://git.openjdk.java.net/jdk/pull/5179/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=10 Stats: 63 lines in 2 files changed: 59 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5179/head:pull/5179 PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sat Nov 6 15:16:53 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 6 Nov 2021 15:16:53 GMT Subject: RFR: 8276779: ChannelInputStream.transferTo() uses FileChannel.transferTo(WritableByteChannel) [v10] In-Reply-To: References: Message-ID: <1JrP_SYEixYdOH9_ayxuaFweGbpVBR-b7E6SKsOXe_4=.ce0ddbb7-a48e-4dd7-9d9f-f698586d27ca@github.com> 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). >> >> **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). > > 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. **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WritableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From itakiguchi at openjdk.java.net Sat Nov 6 16:07:33 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Sat, 6 Nov 2021 16:07:33 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: <3eD0pM--_hnZO0XlBHng-IXMjBXb6R_r1BMvxj6VT_4=.55d11749-f83d-4860-9b09-abfac2c2b08f@github.com> On Fri, 5 Nov 2021 20:22:03 GMT, Naoto Sato wrote: >> Do you need to add test? > >> Do you need to add test? > > I would if I could, but specifying the environment dependent settings in the test would be fragile and error-prone, so I did not add a test but marked the issue as `noreg-hard`. @naotoj I'm not reviewer. Could you explain more detail, why JEP-400 needs to touch sun.jnu.encoding system property's fallback ? ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Sat Nov 6 16:23:37 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 6 Nov 2021 16:23:37 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: <3eD0pM--_hnZO0XlBHng-IXMjBXb6R_r1BMvxj6VT_4=.55d11749-f83d-4860-9b09-abfac2c2b08f@github.com> References: <3eD0pM--_hnZO0XlBHng-IXMjBXb6R_r1BMvxj6VT_4=.55d11749-f83d-4860-9b09-abfac2c2b08f@github.com> Message-ID: <6ix4cThx5LeGgbO6q4SeB0RN54uooqAhPHlNPaK3IE8=.92589901-9f4e-45c1-b221-e62271799743@github.com> On Sat, 6 Nov 2021 16:04:13 GMT, Ichiroh Takiguchi wrote: > Could you explain more detail, why JEP-400 needs to touch sun.jnu.encoding system property's fallback ? This is about running on unusual configurations where the native encoding (native.encoding and sun.jnu.encoding) doesn't name a charset in java.base. There has been several reports of NPE in such cases. Now that the default charset is UTF-8 it means there is a sane fallback so the VM can startup. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From itakiguchi at openjdk.java.net Sat Nov 6 17:02:32 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Sat, 6 Nov 2021 17:02:32 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: <6ix4cThx5LeGgbO6q4SeB0RN54uooqAhPHlNPaK3IE8=.92589901-9f4e-45c1-b221-e62271799743@github.com> References: <3eD0pM--_hnZO0XlBHng-IXMjBXb6R_r1BMvxj6VT_4=.55d11749-f83d-4860-9b09-abfac2c2b08f@github.com> <6ix4cThx5LeGgbO6q4SeB0RN54uooqAhPHlNPaK3IE8=.92589901-9f4e-45c1-b221-e62271799743@github.com> Message-ID: On Sat, 6 Nov 2021 16:20:41 GMT, Alan Bateman wrote: >> @naotoj >> I'm not reviewer. >> Could you explain more detail, why JEP-400 needs to touch sun.jnu.encoding system property's fallback ? > >> Could you explain more detail, why JEP-400 needs to touch sun.jnu.encoding system property's fallback ? > > This is about running on unusual configurations where the native encoding (native.encoding and sun.jnu.encoding) doesn't name a charset in java.base. There has been several reports of NPE in such cases. Now that the default charset is UTF-8 it means there is a sane fallback so the VM can startup. Thanks @AlanBateman . In my understanding, sun.jnu.encoding property may be related file system access. Java may not be access to appropriate file. I mean if the file name has malformed character, it may be changed to "?". In this case, unexpected file access may be happened. 8-bit pass-through may be better... ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Sat Nov 6 17:28:37 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 6 Nov 2021 17:28:37 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: <3eD0pM--_hnZO0XlBHng-IXMjBXb6R_r1BMvxj6VT_4=.55d11749-f83d-4860-9b09-abfac2c2b08f@github.com> <6ix4cThx5LeGgbO6q4SeB0RN54uooqAhPHlNPaK3IE8=.92589901-9f4e-45c1-b221-e62271799743@github.com> Message-ID: On Sat, 6 Nov 2021 16:59:12 GMT, Ichiroh Takiguchi wrote: > In my understanding, sun.jnu.encoding property may be related file system access. > Java may not be access to appropriate file. Yes, it's a JDK internal property with the charset name to use when decoding or encoding file names (not the file content). The issue in this PR is about what to do when starting in unsupported configurations. In the recent releases the JDK will typically NPE or fail with an exception. Since JEP 400 this no longer impacts the default charset because it is UTF-8. This moves the problem on to choosing a fallback for places in the JDK that use the value of native.encoding or sun.jnu.encoding. I think the only choices to either fail at startup or default to UTF-8 as proposed. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From duke at openjdk.java.net Sat Nov 6 19:19:36 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 6 Nov 2021 19:19:36 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels In-Reply-To: References: <4aYyUY5raNV7PBhtlbPL9Mrqaoy4eeLct4uoq4jI1KI=.500ab3f2-1981-4a4d-8ea5-52da621f3a4d@github.com> Message-ID: On Thu, 19 Aug 2021 18:25:39 GMT, Alan Bateman wrote: >>> I had hoped that ThrowingLongSupplier would go away. If you keep your 2-arg transfer method then we should be able to implementation transferTo very simply, something like >>> >>> ``` >>> public long transferTo(OutputStream out) throws IOException { >>> if (ch instanceof FileChannel fc >>> && out instanceof ChannelOutputStream cos) { >>> WritableByteChannel target = cos.channel(); >>> if (target instanceof SelectableChannel sc) { >>> synchronized (sc.blockingLock()) { >>> if (!sc.isBlocking()) >>> throw new IllegalBlockingModeException(); >>> return transfer(fc, target); >>> } >>> } >>> return transfer(fc, target); >>> } >>> return super.transferTo(out); >>> } >>> ``` >> >> This is not true. It will only check the blocking mode for the target. But technically it is possible that someone writes an implementation of FileChannel which implements SelectableChannel. In that case it is needed to check the blocking mode on the source, too. So either we (a) ignore this possibility, (b) write a very complex code which calls transfer(fc, target) in FOUR code paths not just two, or (c) we keep the ThrowingLongSupplier as an elegant way to perform the 2x2 matrix. > >> This is not true. It will only check the blocking mode for the target. But technically it is possible that someone writes an implementation of FileChannel which implements SelectableChannel. In that case it is needed to check the blocking mode on the source, too. So either we (a) ignore this possibility, (b) write a very complex code which calls transfer(fc, target) in FOUR code paths not just two, or (c) we keep the ThrowingLongSupplier as an elegant way to perform the 2x2 matrix. > > SelectableChannel is an abstract class, not an interface so you can't extend both FileChannel and SelectableChannel. So when the source channel is a FileChannel then it should only be concerned with whether the target channel is a SelectableChannel or not. I think we can keep it very simple, along the lines of the method I pasted in above. > > If you choose to include the case where the target is a SelectableChannel (and I have no objection to doing that) then the test needs to exercise that code. This means the test needs an input stream created on a source file/FileChannel, and an output stream created an channel that is WritableByteChannel & SelectableChannel. A Pipe.SinkChannel or a connected SocketChannel will do fine. If you choose to leave out selectable channels for the first PR then file -> file is okay, which I think is what your current test is doing. @AlanBateman Kindly requesting review. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From naoto at openjdk.java.net Sat Nov 6 23:26:36 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 6 Nov 2021 23:26:36 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: <3eD0pM--_hnZO0XlBHng-IXMjBXb6R_r1BMvxj6VT_4=.55d11749-f83d-4860-9b09-abfac2c2b08f@github.com> <6ix4cThx5LeGgbO6q4SeB0RN54uooqAhPHlNPaK3IE8=.92589901-9f4e-45c1-b221-e62271799743@github.com> Message-ID: On Sat, 6 Nov 2021 17:25:39 GMT, Alan Bateman wrote: >> Thanks @AlanBateman . >> In my understanding, sun.jnu.encoding property may be related file system access. >> Java may not be access to appropriate file. >> I mean if the file name has malformed character, it may be changed to "?". >> In this case, unexpected file access may be happened. >> 8-bit pass-through may be better... > >> In my understanding, sun.jnu.encoding property may be related file system access. >> Java may not be access to appropriate file. > > Yes, it's a JDK internal property with the charset name to use when decoding or encoding file names (not the file content). The issue in this PR is about what to do when starting in unsupported configurations. In the recent releases the JDK will typically NPE or fail with an exception. Since JEP 400 this no longer impacts the default charset because it is UTF-8. This moves the problem on to choosing a fallback for places in the JDK that use the value of native.encoding or sun.jnu.encoding. I think the only choices to either fail at startup or default to UTF-8 as proposed. Thanks, @AlanBateman for the explanation. @takiguc, this is not part of JEP400, but really is a bug fix where the launcher fails to start with an NPE (on recent releases), which incorrectly called `new String(byte[])` assuming it would default to iso-8859-1, by calling `Charset.defaultCharset()`. NPE is thrown because at that `initPhase1`, system property is yet to be initialized. The gist of the change is to replace it with `new String(byte[], UTF_8) so that it does not call `Charset.defaultCharset()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Sun Nov 7 09:10:33 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 7 Nov 2021 09:10:33 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels In-Reply-To: References: <4aYyUY5raNV7PBhtlbPL9Mrqaoy4eeLct4uoq4jI1KI=.500ab3f2-1981-4a4d-8ea5-52da621f3a4d@github.com> Message-ID: <97qtHKjfZNhFbbOgGS93llczeyix_VUG5AJWW7RHi6Q=.1f4d1de3-ad47-48f2-be78-7946b1a78f64@github.com> On Thu, 19 Aug 2021 18:25:39 GMT, Alan Bateman wrote: >>> I had hoped that ThrowingLongSupplier would go away. If you keep your 2-arg transfer method then we should be able to implementation transferTo very simply, something like >>> >>> ``` >>> public long transferTo(OutputStream out) throws IOException { >>> if (ch instanceof FileChannel fc >>> && out instanceof ChannelOutputStream cos) { >>> WritableByteChannel target = cos.channel(); >>> if (target instanceof SelectableChannel sc) { >>> synchronized (sc.blockingLock()) { >>> if (!sc.isBlocking()) >>> throw new IllegalBlockingModeException(); >>> return transfer(fc, target); >>> } >>> } >>> return transfer(fc, target); >>> } >>> return super.transferTo(out); >>> } >>> ``` >> >> This is not true. It will only check the blocking mode for the target. But technically it is possible that someone writes an implementation of FileChannel which implements SelectableChannel. In that case it is needed to check the blocking mode on the source, too. So either we (a) ignore this possibility, (b) write a very complex code which calls transfer(fc, target) in FOUR code paths not just two, or (c) we keep the ThrowingLongSupplier as an elegant way to perform the 2x2 matrix. > >> This is not true. It will only check the blocking mode for the target. But technically it is possible that someone writes an implementation of FileChannel which implements SelectableChannel. In that case it is needed to check the blocking mode on the source, too. So either we (a) ignore this possibility, (b) write a very complex code which calls transfer(fc, target) in FOUR code paths not just two, or (c) we keep the ThrowingLongSupplier as an elegant way to perform the 2x2 matrix. > > SelectableChannel is an abstract class, not an interface so you can't extend both FileChannel and SelectableChannel. So when the source channel is a FileChannel then it should only be concerned with whether the target channel is a SelectableChannel or not. I think we can keep it very simple, along the lines of the method I pasted in above. > > If you choose to include the case where the target is a SelectableChannel (and I have no objection to doing that) then the test needs to exercise that code. This means the test needs an input stream created on a source file/FileChannel, and an output stream created an channel that is WritableByteChannel & SelectableChannel. A Pipe.SinkChannel or a connected SocketChannel will do fine. If you choose to leave out selectable channels for the first PR then file -> file is okay, which I think is what your current test is doing. > @AlanBateman Kindly requesting review. :-) The implementation change looks correct, it's as we discussed a few months ago: InputStream::transferTo needs to throw IllegalBlockingModeException when the source is an input stream backed by a FileChannel and the output stream is backed by a channel configured non-blocking. While not a change to existing behavior, I'm mulling over whether we should clarify the specification of Channels.newInputStream. The current spec is: "The read methods of the resulting stream will throw an IllegalBlockingModeException if invoked while the underlying channel is in non-blocking mode. " We can expand this to "The read and transferTo methods ...". We could also add "The transferTo method will also throw an IllegalBlockingModeException if invoked to transfer bytes to an output stream that writes to an underlying channel in non-blocking mode". I'm not saying we have to update the API docs as part of this PR, I'm just pointing out that the existing spec wasn't updated when InputStream.transferTo was added, it probably should have been. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sun Nov 7 10:58:41 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 7 Nov 2021 10:58:41 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v11] In-Reply-To: References: Message-ID: On Sat, 6 Nov 2021 15:16:52 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). >> >> **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). > > Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo() > > This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferTo(WritableByteChannel), including special treatment of SelectableByteChannel. > > Signed-off-by: Markus Karg (sorry for accidentally closing and reopening this MR, this was not intentional) ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sun Nov 7 11:59:38 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 7 Nov 2021 11:59:38 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels In-Reply-To: <97qtHKjfZNhFbbOgGS93llczeyix_VUG5AJWW7RHi6Q=.1f4d1de3-ad47-48f2-be78-7946b1a78f64@github.com> References: <4aYyUY5raNV7PBhtlbPL9Mrqaoy4eeLct4uoq4jI1KI=.500ab3f2-1981-4a4d-8ea5-52da621f3a4d@github.com> <97qtHKjfZNhFbbOgGS93llczeyix_VUG5AJWW7RHi6Q=.1f4d1de3-ad47-48f2-be78-7946b1a78f64@github.com> Message-ID: On Sun, 7 Nov 2021 09:07:31 GMT, Alan Bateman wrote: > > @AlanBateman Kindly requesting review. :-) > > The implementation change looks correct, it's as we discussed a few months ago: InputStream::transferTo needs to throw IllegalBlockingModeException when the source is an input stream backed by a FileChannel and the output stream is backed by a channel configured non-blocking. > > While not a change to existing behavior, I'm mulling over whether we should clarify the specification of Channels.newInputStream. The current spec is: > > "The read methods of the resulting stream will throw an IllegalBlockingModeException if invoked while the underlying channel is in non-blocking mode. " > > We can expand this to "The read and transferTo methods ...". > > We could also add "The transferTo method will also throw an IllegalBlockingModeException if invoked to transfer bytes to an output stream that writes to an underlying channel in non-blocking mode". > > I'm not saying we have to update the API docs as part of this PR, I'm just pointing out that the existing spec wasn't updated when InputStream.transferTo was added, it probably should have been. I would be happy to extend it in that way you proposed. Shall I do that? ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From itakiguchi at openjdk.java.net Sun Nov 7 13:06:32 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Sun, 7 Nov 2021 13:06:32 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 17:31:50 GMT, Naoto Sato wrote: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. If this issue is not a part of JEP-400, I think UTF_8 may not be only solution for sun/nio/fs/Util.java. Please explain why UTF_8 is better than ISO_8859_1. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From duke at openjdk.java.net Sun Nov 7 16:54:40 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 7 Nov 2021 16:54:40 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 Please keep this PR open. More commits will follow on the next weeks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From naoto at openjdk.java.net Mon Nov 8 05:00:34 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 8 Nov 2021 05:00:34 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 17:31:50 GMT, Naoto Sato wrote: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. The same rationale as JEP 400, that UTF-8 is the de-facto encoding these days. This is for the exceptional case where JDK does not support the native encoding, choosing fallback as UTF-8 is not a bad choice IMO. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Mon Nov 8 09:47:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 8 Nov 2021 09:47:39 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Sun, 7 Nov 2021 13:03:10 GMT, Ichiroh Takiguchi wrote: > If this issue is not a part of JEP-400, I think UTF_8 may not be only solution for sun/nio/fs/Util.java. > Please explain why UTF_8 is better than ISO_8859_1. Just to add to Naoto's comment. When the JDK starts in unusual/unsupported configurations then it needs a default for the stdout/stderr print streams, for encoding/decoding files paths in java.io, and for encoding/decoding files paths in the java.nio.file implementation. It's important that the latter two are the same, having one be UTF-8 and the other be 8859-1 won't work. There may be an argument that the JDK should emit a warning at startup. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Mon Nov 8 11:50:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 8 Nov 2021 11:50:46 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels In-Reply-To: References: <4aYyUY5raNV7PBhtlbPL9Mrqaoy4eeLct4uoq4jI1KI=.500ab3f2-1981-4a4d-8ea5-52da621f3a4d@github.com> <97qtHKjfZNhFbbOgGS93llczeyix_VUG5AJWW7RHi6Q=.1f4d1de3-ad47-48f2-be78-7946b1a78f64@github.com> Message-ID: On Sun, 7 Nov 2021 11:56:03 GMT, Markus KARG wrote: > I would be happy to extend it in that way you proposed. Shall I do that? Okay, let's do that but it will require a CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Mon Nov 8 12:05:32 2021 From: duke at openjdk.java.net (Markus KARG) Date: Mon, 8 Nov 2021 12:05:32 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels In-Reply-To: References: <4aYyUY5raNV7PBhtlbPL9Mrqaoy4eeLct4uoq4jI1KI=.500ab3f2-1981-4a4d-8ea5-52da621f3a4d@github.com> <97qtHKjfZNhFbbOgGS93llczeyix_VUG5AJWW7RHi6Q=.1f4d1de3-ad47-48f2-be78-7946b1a78f64@github.com> Message-ID: On Mon, 8 Nov 2021 11:47:25 GMT, Alan Bateman wrote: > > I would be happy to extend it in that way you proposed. Shall I do that? > > Okay, let's do that but it will require a CSR. Uhm... what actually is a CSR? ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From itakiguchi at openjdk.java.net Mon Nov 8 13:00:35 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 8 Nov 2021 13:00:35 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 09:44:34 GMT, Alan Bateman wrote: >> If this issue is not a part of JEP-400, I think UTF_8 may not be only solution for sun/nio/fs/Util.java. >> Please explain why UTF_8 is better than ISO_8859_1. > >> If this issue is not a part of JEP-400, I think UTF_8 may not be only solution for sun/nio/fs/Util.java. >> Please explain why UTF_8 is better than ISO_8859_1. > > Just to add to Naoto's comment. When the JDK starts in unusual/unsupported configurations then it needs a default for the stdout/stderr print streams, for encoding/decoding files paths in java.io, and for encoding/decoding files paths in the java.nio.file implementation. It's important that the latter two are the same, having one be UTF-8 and the other be 8859-1 won't work. > > There may be an argument that the JDK should emit a warning at startup. Thanks @AlanBateman . Yeah, I got a message from my co-worker. He said unmappable conversion was still there even if ISO8859_1, and there was no big difference between ISO8859_1 and UTF_8. I'm very sorry for your confusion... ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From bpb at openjdk.java.net Mon Nov 8 16:59:46 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 8 Nov 2021 16:59:46 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v11] In-Reply-To: References: Message-ID: On Sat, 6 Nov 2021 15:16:52 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). >> >> **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). > > Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo() > > This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferTo(WritableByteChannel), including special treatment of SelectableByteChannel. > > Signed-off-by: Markus Karg https://wiki.openjdk.java.net/display/csr/Main ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From bpb at openjdk.java.net Mon Nov 8 17:32:51 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 8 Nov 2021 17:32:51 GMT Subject: RFR: 8276808: java/nio/channels/Channels/TransferTo.java timed out Message-ID: The test looks to have been about 95% complete when it timed out, so try increasing the timeout value by 50% to 1.5 the default value. ------------- Commit messages: - 8276808: java/nio/channels/Channels/TransferTo.java timed out Changes: https://git.openjdk.java.net/jdk/pull/6299/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6299&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276808 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6299.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6299/head:pull/6299 PR: https://git.openjdk.java.net/jdk/pull/6299 From duke at openjdk.java.net Mon Nov 8 18:01:37 2021 From: duke at openjdk.java.net (Markus KARG) Date: Mon, 8 Nov 2021 18:01:37 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v11] In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 16:56:20 GMT, Brian Burkhalter wrote: > https://wiki.openjdk.java.net/display/csr/Main Understood, thanks for the pointer. I will file a CSR then. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From lancea at openjdk.java.net Mon Nov 8 19:16:36 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 8 Nov 2021 19:16:36 GMT Subject: RFR: 8276808: java/nio/channels/Channels/TransferTo.java timed out In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 17:24:47 GMT, Brian Burkhalter wrote: > The test looks to have been about 95% complete when it timed out, so try increasing the timeout value by 50% to 1.5 the default value. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6299 From shade at openjdk.java.net Tue Nov 9 10:13:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Nov 2021 10:13:58 GMT Subject: RFR: 8276845: (fs) java/nio/file/spi/SetDefaultProvider.java fails on x86_32 Message-ID: x86_32 takes a path that requires `newFileChannel` implemented in `TestProvider`. Otherwise the test fails with the exception. The implementation is the same as for `newByteChannel`. Additional testing: - [x] Linux x86_32 fastdebug, test now passes - [x] Linux x86_64 fastdebug, test still passes ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/6307/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6307&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276845 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6307.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6307/head:pull/6307 PR: https://git.openjdk.java.net/jdk/pull/6307 From alanb at openjdk.java.net Tue Nov 9 10:18:37 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 9 Nov 2021 10:18:37 GMT Subject: RFR: 8276845: (fs) java/nio/file/spi/SetDefaultProvider.java fails on x86_32 In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 10:07:07 GMT, Aleksey Shipilev wrote: > x86_32 takes a path that requires `newFileChannel` implemented in `TestProvider`. Otherwise the test fails with the exception. The implementation is the same as for `newByteChannel`. > > Additional testing: > - [x] Linux x86_32 fastdebug, test now passes > - [x] Linux x86_64 fastdebug, test still passes Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6307 From alanb at openjdk.java.net Tue Nov 9 11:03:36 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 9 Nov 2021 11:03:36 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v11] In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 17:58:51 GMT, Markus KARG wrote: > > https://wiki.openjdk.java.net/display/csr/Main > > Understood, thanks for the pointer. I will file a CSR then. Thanks. If you update if the PR with the javadoc changes then we can agree them here before you create the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From shade at openjdk.java.net Tue Nov 9 11:15:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Nov 2021 11:15:40 GMT Subject: RFR: 8276808: java/nio/channels/Channels/TransferTo.java timed out In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 17:24:47 GMT, Brian Burkhalter wrote: > The test looks to have been about 95% complete when it timed out, so try increasing the timeout value by 50% to 1.5 the default value. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6299 From duke at openjdk.java.net Tue Nov 9 14:57:38 2021 From: duke at openjdk.java.net (Sherzod Mamadaliev) Date: Tue, 9 Nov 2021 14:57:38 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 17:31:50 GMT, Naoto Sato wrote: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. LGTM ------------- Marked as reviewed by mamadaliev at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/6282 From bpb at openjdk.java.net Tue Nov 9 19:21:38 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 9 Nov 2021 19:21:38 GMT Subject: Integrated: 8276808: java/nio/channels/Channels/TransferTo.java timed out In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 17:24:47 GMT, Brian Burkhalter wrote: > The test looks to have been about 95% complete when it timed out, so try increasing the timeout value by 50% to 1.5 the default value. This pull request has now been integrated. Changeset: dde959df Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/dde959dfcef01897fdf51f820d414402e6309b8d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8276808: java/nio/channels/Channels/TransferTo.java timed out Reviewed-by: lancea, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/6299 From naoto at openjdk.java.net Tue Nov 9 19:38:01 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 9 Nov 2021 19:38:01 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2] In-Reply-To: References: Message-ID: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Emit a warning on unsupported jnu encoding ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6282/files - new: https://git.openjdk.java.net/jdk/pull/6282/files/0b9f6df3..d3c240c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=00-01 Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6282/head:pull/6282 PR: https://git.openjdk.java.net/jdk/pull/6282 From naoto at openjdk.java.net Tue Nov 9 19:41:34 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 9 Nov 2021 19:41:34 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 09:44:34 GMT, Alan Bateman wrote: > There may be an argument that the JDK should emit a warning at startup. Updated to emit a warning, if `sun.jnu.encoding` is not supported. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From rriggs at openjdk.java.net Tue Nov 9 20:42:37 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 9 Nov 2021 20:42:37 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2] In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Emit a warning on unsupported jnu encoding Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From iris at openjdk.java.net Tue Nov 9 21:32:36 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 9 Nov 2021 21:32:36 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2] In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Emit a warning on unsupported jnu encoding Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From duke at openjdk.java.net Tue Nov 9 21:36:38 2021 From: duke at openjdk.java.net (Markus KARG) Date: Tue, 9 Nov 2021 21:36:38 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v11] In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 11:00:33 GMT, Alan Bateman wrote: > > Understood, thanks for the pointer. I will file a CSR then. > > Thanks. If you update if the PR with the javadoc changes then we can agree them here before you create the CSR. Ok I will do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From itakiguchi at openjdk.java.net Wed Nov 10 03:34:38 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Wed, 10 Nov 2021 03:34:38 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 19:38:46 GMT, Naoto Sato wrote: >>> If this issue is not a part of JEP-400, I think UTF_8 may not be only solution for sun/nio/fs/Util.java. >>> Please explain why UTF_8 is better than ISO_8859_1. >> >> Just to add to Naoto's comment. When the JDK starts in unusual/unsupported configurations then it needs a default for the stdout/stderr print streams, for encoding/decoding files paths in java.io, and for encoding/decoding files paths in the java.nio.file implementation. It's important that the latter two are the same, having one be UTF-8 and the other be 8859-1 won't work. >> >> There may be an argument that the JDK should emit a warning at startup. > >> There may be an argument that the JDK should emit a warning at startup. > > Updated to emit a warning, if `sun.jnu.encoding` is not supported. Hello @naotoj . I appreciate your code update. I'd like to confirm one thing. If you could not recreate this issue on your test machine, please ignore this message. I tested your code on my CentOS7 x86_64. I saw following exception. $ git log --oneline | head e91e9d85327 8276721: G1: Refine G1EvacFailureObjectsSet::iterate 8822d41fdcc 8274736: Concurrent read/close of SSLSockets causes SSLSessions to be invalidated unnecessarily c1e41fe38bb 8276842: G1: Only calculate size in bytes from words when needed c8b0ee6b8a0 8276833: G1: Make G1EvacFailureRegions::par_iterate const 0699220830a 8268882: C2: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc d7012fbd604 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary f9024d0606e 8230130: javadoc search result dialog shows cut off headers for long results 055de6f5662 8223358: Incorrect HTML structure in annotation pages a60e91259ba 8198626: java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac dde959dfcef 8276808: java/nio/channels/Channels/TransferTo.java timed out $ cat Hello.java public class Hello { public static void main(String[] args) throws Exception { System.out.println("Hello"); } } $ env LC_ALL=kk_KZ.pt154 locale LANG=ja_JP.UTF-8 LC_CTYPE="kk_KZ.pt154" LC_NUMERIC="kk_KZ.pt154" LC_TIME="kk_KZ.pt154" LC_COLLATE="kk_KZ.pt154" LC_MONETARY="kk_KZ.pt154" LC_MESSAGES="kk_KZ.pt154" LC_PAPER="kk_KZ.pt154" LC_NAME="kk_KZ.pt154" LC_ADDRESS="kk_KZ.pt154" LC_TELEPHONE="kk_KZ.pt154" LC_MEASUREMENT="kk_KZ.pt154" LC_IDENTIFICATION="kk_KZ.pt154" LC_ALL=kk_KZ.pt154 $ env LC_ALL=kk_KZ.pt154 ./build/linux-x86_64-server-release/images/jdk/bin/java Hello.java WARNING: The encoding of the underlying platform's file system is not supported by the JVM: PT154 Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.util.ServiceConfigurationError: java.nio.charset.spi.CharsetProvider: Unable to load sun.nio.cs.ext.ExtendedCharsets at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586) at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:861) at java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.hasNext(ServiceLoader.java:1084) at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309) at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393) at java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:428) at java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:422) at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) at java.base/java.nio.charset.Charset$ExtendedProviderHolder.extendedProviders(Charset.java:422) at java.base/java.nio.charset.Charset$ExtendedProviderHolder.(Charset.java:418) at java.base/java.nio.charset.Charset.lookupExtendedCharset(Charset.java:442) at java.base/java.nio.charset.Charset.lookup2(Charset.java:472) at java.base/java.nio.charset.Charset.lookup(Charset.java:460) at java.base/java.nio.charset.Charset.isSupported(Charset.java:501) at java.base/sun.launcher.LauncherHelper.makePlatformString(LauncherHelper.java:891) Caused by: java.lang.ExceptionInInitializerError at java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:51) at java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46) at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39) at java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider.java:55) at java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvider.java:41) at java.base/sun.nio.fs.DefaultFileSystemProvider.(DefaultFileSystemProvider.java:35) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:114) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:103) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:101) at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:101) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:94) at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:183) at java.base/java.nio.file.Path.of(Path.java:147) at java.base/java.nio.file.Paths.get(Paths.java:69) at java.base/jdk.internal.jimage.ImageReaderFactory.(ImageReaderFactory.java:51) at java.base/jdk.internal.module.SystemModuleFinders$SystemImage.(SystemModuleFinders.java:385) at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.findImageLocation(SystemModuleFinders.java:429) at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.read(SystemModuleFinders.java:483) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:809) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741) at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:633) at java.base/java.lang.Class.forName(Class.java:577) at java.base/java.lang.Class.forName(Class.java:552) at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:859) ... 13 more Caused by: java.lang.NullPointerException: Cannot read the array length because "" is null at java.base/java.nio.charset.Charset.lookupExtendedCharset(Charset.java:443) at java.base/java.nio.charset.Charset.lookup2(Charset.java:472) at java.base/java.nio.charset.Charset.lookup(Charset.java:460) at java.base/java.nio.charset.Charset.forName(Charset.java:556) at java.base/sun.nio.fs.Util.(Util.java:41) ... 40 more ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Wed Nov 10 06:43:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 10 Nov 2021 06:43:43 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 03:31:11 GMT, Ichiroh Takiguchi wrote: > I tested your code on my CentOS7 x86_64. I saw following exception. This doesn't surprise me. It would be be useful if you could do the same experiment with main line and JDK 17 too. There have been several reports of NPE when trying to startup in environments where the locale does not map to a charset that the JDK supports. In your output I see "WARNING: The encoding of the underlying platform's file system is not supported by the JVM: PT154". Thereafter what you are seeing a recursive initialisation issue. To break this cycle we need jnuEncoding to be set before initialising the file system. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From duke at openjdk.java.net Wed Nov 10 07:21:14 2021 From: duke at openjdk.java.net (Markus KARG) Date: Wed, 10 Nov 2021 07:21:14 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v12] In-Reply-To: References: Message-ID: > 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). > > **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). Markus KARG has updated the pull request incrementally with one additional commit since the last revision: JavaDoc proposal by Alan Bateman ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5179/files - new: https://git.openjdk.java.net/jdk/pull/5179/files/d762ba1b..fcf616e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=10-11 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5179/head:pull/5179 PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Wed Nov 10 07:21:15 2021 From: duke at openjdk.java.net (Markus KARG) Date: Wed, 10 Nov 2021 07:21:15 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v11] In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 21:33:19 GMT, Markus KARG wrote: > If you update if the PR with the javadoc changes then we can agree them here before you create the CSR. Please find and discuss the CSR Javadoc proposal by @AlanBateman in https://github.com/openjdk/jdk/pull/5179/commits/fcf616e2b86f92ad20425e018c42be2fe4cef0df. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From alanb at openjdk.java.net Wed Nov 10 08:38:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 10 Nov 2021 08:38:46 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v12] In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 07:21:14 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). >> >> **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > JavaDoc proposal by Alan Bateman > > If you update if the PR with the javadoc changes then we can agree them here before you create the CSR. > > Please find and discuss the CSR Javadoc proposal by @AlanBateman in [fcf616e](https://github.com/openjdk/jdk/commit/fcf616e2b86f92ad20425e018c42be2fe4cef0df). Thanks. Thanks, I'm happy with this. As I suggested this wording then it would be good if @bplb also reviews the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From shade at openjdk.java.net Wed Nov 10 09:53:44 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 10 Nov 2021 09:53:44 GMT Subject: RFR: 8276845: (fs) java/nio/file/spi/SetDefaultProvider.java fails on x86_32 In-Reply-To: References: Message-ID: <729s_hc1IS25nt2BOv9vNoDxAXdSefac0CLDSKsN3BQ=.199324aa-91c2-4bbc-b757-6a99fb9fd2c4@github.com> On Tue, 9 Nov 2021 10:07:07 GMT, Aleksey Shipilev wrote: > x86_32 takes a path that requires `newFileChannel` implemented in `TestProvider`. Otherwise the test fails with the exception. The implementation is the same as for `newByteChannel`. > > Additional testing: > - [x] Linux x86_32 fastdebug, test now passes > - [x] Linux x86_64 fastdebug, test still passes Thanks Alan. Need another reviewer, I think. Ok, cool. ------------- PR: https://git.openjdk.java.net/jdk/pull/6307 From alanb at openjdk.java.net Wed Nov 10 09:53:45 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 10 Nov 2021 09:53:45 GMT Subject: RFR: 8276845: (fs) java/nio/file/spi/SetDefaultProvider.java fails on x86_32 In-Reply-To: <729s_hc1IS25nt2BOv9vNoDxAXdSefac0CLDSKsN3BQ=.199324aa-91c2-4bbc-b757-6a99fb9fd2c4@github.com> References: <729s_hc1IS25nt2BOv9vNoDxAXdSefac0CLDSKsN3BQ=.199324aa-91c2-4bbc-b757-6a99fb9fd2c4@github.com> Message-ID: On Wed, 10 Nov 2021 09:45:34 GMT, Aleksey Shipilev wrote: > Thanks Alan. Need another reviewer, I think. No, one Reviewer working in the area is okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/6307 From shade at openjdk.java.net Wed Nov 10 09:53:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 10 Nov 2021 09:53:45 GMT Subject: Integrated: 8276845: (fs) java/nio/file/spi/SetDefaultProvider.java fails on x86_32 In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 10:07:07 GMT, Aleksey Shipilev wrote: > x86_32 takes a path that requires `newFileChannel` implemented in `TestProvider`. Otherwise the test fails with the exception. The implementation is the same as for `newByteChannel`. > > Additional testing: > - [x] Linux x86_32 fastdebug, test now passes > - [x] Linux x86_64 fastdebug, test still passes This pull request has now been integrated. Changeset: 0f463a7b Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/0f463a7bf73791eda9404882ff63daf9040399bb Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod 8276845: (fs) java/nio/file/spi/SetDefaultProvider.java fails on x86_32 Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/6307 From naoto at openjdk.java.net Wed Nov 10 17:26:34 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 10 Nov 2021 17:26:34 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 03:31:11 GMT, Ichiroh Takiguchi wrote: >>> There may be an argument that the JDK should emit a warning at startup. >> >> Updated to emit a warning, if `sun.jnu.encoding` is not supported. > > Hello @naotoj . > I appreciate your code update. > I'd like to confirm one thing. > If you could not recreate this issue on your test machine, please ignore this message. > > I tested your code on my CentOS7 x86_64. > I saw following exception. > > $ git log --oneline | head > e91e9d85327 8276721: G1: Refine G1EvacFailureObjectsSet::iterate > 8822d41fdcc 8274736: Concurrent read/close of SSLSockets causes SSLSessions to be invalidated unnecessarily > c1e41fe38bb 8276842: G1: Only calculate size in bytes from words when needed > c8b0ee6b8a0 8276833: G1: Make G1EvacFailureRegions::par_iterate const > 0699220830a 8268882: C2: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc > d7012fbd604 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary > f9024d0606e 8230130: javadoc search result dialog shows cut off headers for long results > 055de6f5662 8223358: Incorrect HTML structure in annotation pages > a60e91259ba 8198626: java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac > dde959dfcef 8276808: java/nio/channels/Channels/TransferTo.java timed out > $ git status -s > M src/java.base/share/classes/java/lang/System.java > M src/java.base/share/classes/sun/nio/fs/Util.java > M src/java.base/share/native/libjava/jni_util.c > ?? 8275007.patch > ?? Hello.java > $ cat Hello.java > public class Hello { > public static void main(String[] args) throws Exception { > System.out.println("Hello"); > } > } > $ env LC_ALL=kk_KZ.pt154 locale > LANG=ja_JP.UTF-8 > LC_CTYPE="kk_KZ.pt154" > LC_NUMERIC="kk_KZ.pt154" > LC_TIME="kk_KZ.pt154" > LC_COLLATE="kk_KZ.pt154" > LC_MONETARY="kk_KZ.pt154" > LC_MESSAGES="kk_KZ.pt154" > LC_PAPER="kk_KZ.pt154" > LC_NAME="kk_KZ.pt154" > LC_ADDRESS="kk_KZ.pt154" > LC_TELEPHONE="kk_KZ.pt154" > LC_MEASUREMENT="kk_KZ.pt154" > LC_IDENTIFICATION="kk_KZ.pt154" > LC_ALL=kk_KZ.pt154 > $ env LC_ALL=kk_KZ.pt154 ./build/linux-x86_64-server-release/images/jdk/bin/java Hello.java > WARNING: The encoding of the underlying platform's file system is not supported by the JVM: PT154 > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.util.ServiceConfigurationError: java.nio.charset.spi.CharsetProvider: Unable to load sun.nio.cs.ext.ExtendedCharsets > at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586) > at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:861) > at java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.hasNext(ServiceLoader.java:1084) > at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309) > at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393) > at java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:428) > at java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:422) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) > at java.base/java.nio.charset.Charset$ExtendedProviderHolder.extendedProviders(Charset.java:422) > at java.base/java.nio.charset.Charset$ExtendedProviderHolder.(Charset.java:418) > at java.base/java.nio.charset.Charset.lookupExtendedCharset(Charset.java:442) > at java.base/java.nio.charset.Charset.lookup2(Charset.java:472) > at java.base/java.nio.charset.Charset.lookup(Charset.java:460) > at java.base/java.nio.charset.Charset.isSupported(Charset.java:501) > at java.base/sun.launcher.LauncherHelper.makePlatformString(LauncherHelper.java:891) > Caused by: java.lang.ExceptionInInitializerError > at java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:51) > at java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) > at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46) > at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39) > at java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider.java:55) > at java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvider.java:41) > at java.base/sun.nio.fs.DefaultFileSystemProvider.(DefaultFileSystemProvider.java:35) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:114) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:103) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:101) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:101) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:94) > at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:183) > at java.base/java.nio.file.Path.of(Path.java:147) > at java.base/java.nio.file.Paths.get(Paths.java:69) > at java.base/jdk.internal.jimage.ImageReaderFactory.(ImageReaderFactory.java:51) > at java.base/jdk.internal.module.SystemModuleFinders$SystemImage.(SystemModuleFinders.java:385) > at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.findImageLocation(SystemModuleFinders.java:429) > at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.read(SystemModuleFinders.java:483) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:809) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:633) > at java.base/java.lang.Class.forName(Class.java:577) > at java.base/java.lang.Class.forName(Class.java:552) > at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:859) > ... 13 more > Caused by: java.lang.NullPointerException: Cannot read the array length because "" is null > at java.base/java.nio.charset.Charset.lookupExtendedCharset(Charset.java:443) > at java.base/java.nio.charset.Charset.lookup2(Charset.java:472) > at java.base/java.nio.charset.Charset.lookup(Charset.java:460) > at java.base/java.nio.charset.Charset.forName(Charset.java:556) > at java.base/sun.nio.fs.Util.(Util.java:41) > ... 40 more @takiguc, thank you for trying out the fix and informing us of the issue. I've been using Oracle Linux 7.6 with the same locale setting as yours, but I've never seen that failure. Will need to recreate the error and investigate. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From duke at openjdk.java.net Thu Nov 11 07:38:33 2021 From: duke at openjdk.java.net (Markus KARG) Date: Thu, 11 Nov 2021 07:38:33 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v12] In-Reply-To: References: Message-ID: <9nZAJMsgmswOzPH7LRNACzAXNlUJJhq0lw0ZNMXd21U=.ada29744-bd87-4c41-a9ce-b926ab0988ef@github.com> On Wed, 10 Nov 2021 07:21:14 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). >> >> **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > JavaDoc proposal by Alan Bateman The corresponding CSR can be found here: https://bugs.openjdk.java.net/browse/JDK-8276968 ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From alanb at openjdk.java.net Thu Nov 11 07:53:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 11 Nov 2021 07:53:40 GMT Subject: RFR: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB [v4] In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 18:37:39 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 one additional commit since the last revision: > > Indentation We'll need to update testMoreThanTwoGB to delete the temporary files, otherwise it will file up the file system. ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From itakiguchi at openjdk.java.net Thu Nov 11 09:43:44 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 11 Nov 2021 09:43:44 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2] In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Emit a warning on unsupported jnu encoding I don't have Oracle Linux... I tried to find out unsupported locales by using following commands. I used RHEL7.9. $ cat CharsetIsSupported.java import java.nio.charset.Charset; public class CharsetIsSupported { public static void main(String[] args) throws Exception { for(String s : args) { if (!Charset.isSupported(s)) System.out.println(s); } } } $ locale -a | while read LOC; do env LANG=$LOC locale charmap; done | sort -u | xargs ~/jdk-17.0.1/bin/java CharsetIsSupported.java > encoding.lst $ locale -a | while read LOC; do echo -e "$LOC\t\c"; env LANG=$LOC locale charmap; done | grep -f encoding.lst cy_GB ISO-8859-14 cy_GB.iso885914 ISO-8859-14 hy_AM.armscii8 ARMSCII-8 ka_GE GEORGIAN-PS ka_GE.georgianps GEORGIAN-PS kk_KZ PT154 kk_KZ.pt154 PT154 lg_UG ISO-8859-10 lg_UG.iso885910 ISO-8859-10 tg_TJ KOI8-T tg_TJ.koi8t KOI8-T I tried following command, "sun.jnu.encoding" system property was referred following source code. We may need to care about these files. $ find src -type f | xargs grep '"sun.jnu.encoding"' src/java.base/share/classes/java/lang/System.java: var jnuEncoding = props.getProperty("sun.jnu.encoding"); src/java.base/share/classes/java/lang/System.java: props.getProperty("sun.jnu.encoding")); src/java.base/share/classes/jdk/internal/util/SystemProps.java: put(props, "sun.jnu.encoding", raw.propDefault(Raw._sun_jnu_encoding_NDX)); src/java.base/share/classes/sun/launcher/LauncherHelper.java: private static final String encprop = "sun.jnu.encoding"; src/java.base/share/classes/sun/nio/fs/Util.java: GetPropertyAction.privilegedGetProperty("sun.jnu.encoding"), src/java.base/share/native/libjava/jni_util.h: NO_ENCODING_YET = 0, /* "sun.jnu.encoding" not yet set */ src/java.desktop/share/classes/sun/font/SunFontManager.java: String sysEncoding = System.getProperty("sun.jnu.encoding"); ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Thu Nov 11 10:52:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 11 Nov 2021 10:52:41 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2] In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 09:40:14 GMT, Ichiroh Takiguchi wrote: > I don't have Oracle Linux... I tried to find out unsupported locales by using following commands. I used RHEL7.9. In your previous post you used env LC_ALL=kk_KZ.pt154 java Hello.java. Would it be possible to repeat that with JDK 17 and the main-line (latest JDK 18 EA build is okay). I'm wondering if you see the NPE. In any case, our next step here will be to have fallback saved during early startup so that file system and other places don't do the lookup. This seems the sanest way to avoid the recursive initialisation issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From itakiguchi at openjdk.java.net Thu Nov 11 11:02:35 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 11 Nov 2021 11:02:35 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2] In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Emit a warning on unsupported jnu encoding I could see following output on my CentOS7. $ env LC_ALL=kk_KZ.pt154 ~/jdk-17.0.1/bin/java -showversion Hello.java Error occurred during initialization of VM java.lang.NullPointerException at java.lang.System.getProperty(java.base/System.java:918) at sun.security.action.GetPropertyAction.privilegedGetProperty(java.base/GetPropertyAction.java:106) at java.nio.charset.Charset.defaultCharset(java.base/Charset.java:607) at java.lang.String.(java.base/String.java:1412) at java.lang.String.(java.base/String.java:1432) at jdk.internal.util.SystemProps$Raw.platformProperties(java.base/Native Method) at jdk.internal.util.SystemProps$Raw.(java.base/SystemProps.java:234) at jdk.internal.util.SystemProps.initProperties(java.base/SystemProps.java:54) at java.lang.System.initPhase1(java.base/System.java:2089) $ env LC_ALL=kk_KZ.pt154 ~/jdk-18-b22/bin/java -showversion Hello.java Error occurred during initialization of VM java.lang.NullPointerException at java.lang.System.getProperty(java.base/System.java:929) at sun.security.action.GetPropertyAction.privilegedGetProperty(java.base/GetPropertyAction.java:106) at java.nio.charset.Charset.defaultCharset(java.base/Charset.java:646) at java.lang.String.(java.base/String.java:1411) at java.lang.String.(java.base/String.java:1431) at jdk.internal.util.SystemProps$Raw.platformProperties(java.base/Native Method) at jdk.internal.util.SystemProps$Raw.(java.base/SystemProps.java:240) at jdk.internal.util.SystemProps.initProperties(java.base/SystemProps.java:54) at java.lang.System.initPhase1(java.base/System.java:2100) ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Thu Nov 11 12:00:35 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 11 Nov 2021 12:00:35 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v12] In-Reply-To: <9nZAJMsgmswOzPH7LRNACzAXNlUJJhq0lw0ZNMXd21U=.ada29744-bd87-4c41-a9ce-b926ab0988ef@github.com> References: <9nZAJMsgmswOzPH7LRNACzAXNlUJJhq0lw0ZNMXd21U=.ada29744-bd87-4c41-a9ce-b926ab0988ef@github.com> Message-ID: On Thu, 11 Nov 2021 07:35:05 GMT, Markus KARG wrote: > The corresponding CSR can be found here: https://bugs.openjdk.java.net/browse/JDK-8276968 Thanks. I've re-worked the wording to trim it down and put it a style that is more consistent with other CSRs. If you are okay it then press "Finalize" on the CSR to finalize it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Thu Nov 11 12:13:34 2021 From: duke at openjdk.java.net (Markus KARG) Date: Thu, 11 Nov 2021 12:13:34 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v12] In-Reply-To: References: <9nZAJMsgmswOzPH7LRNACzAXNlUJJhq0lw0ZNMXd21U=.ada29744-bd87-4c41-a9ce-b926ab0988ef@github.com> Message-ID: On Thu, 11 Nov 2021 11:57:07 GMT, Alan Bateman wrote: > I've re-worked the wording to trim it down and put it a style that is more consistent with other CSRs. If you are okay it then press "Finalize" on the CSR to finalize it. Thank you for rewording it. This was my very first CSR ever filed. I have pressed "Finalize" now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Thu Nov 11 12:17:45 2021 From: duke at openjdk.java.net (Markus KARG) Date: Thu, 11 Nov 2021 12:17:45 GMT Subject: RFR: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB [v4] In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 07:50:22 GMT, Alan Bateman wrote: > We'll need to update testMoreThanTwoGB to delete the temporary files, otherwise it will file up the file system. I'll file a PR for that. ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From mcimadamore at openjdk.java.net Thu Nov 11 13:03:56 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 11 Nov 2021 13:03:56 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v23] 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 pull request now contains 32 commits: - Merge branch 'master' into JEP-419 - Revert removal of upcall MH customization (This change caused spurious VM crashes, so reverting to baseline) - Further tweak upcall safety considerations - Clarify safety considerations for upcalls - Rename MemorySegment::ofAddressNative to MemorySegment::ofAddress (which is consistent with other restricted factories in VaList and NativeSymbol) - Streamline javadoc for package-info - * Add two new CLinker static methods to compute upcall/downcall method types * Clarify section on CLinker downcall type * Add section on CLinker safety guarantees - Fix TestUpcall * reverse() has a bug, as it doesn't tweak parameter types * reverse() is applied to the wrong MH - Make ArenaAllocator impl more flexible in the face of OOME An ArenaAllocator should remain open for business, even if OOME is thrown in case other allocations can fit the arena size. - Simplify ArenaAllocator impl. The arena should respect its boundaries and never allocate more memory than its size specifies. - ... and 22 more: https://git.openjdk.java.net/jdk/compare/aea09677...8c3860f8 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5907/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=22 Stats: 14686 lines in 193 files changed: 6956 ins; 5120 del; 2610 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 alanb at openjdk.java.net Thu Nov 11 14:11:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 11 Nov 2021 14:11:50 GMT Subject: RFR: 8276763: java/nio/channels/SocketChannel/AdaptorStreams.java fails with "SocketTimeoutException: Read timed out" Message-ID: test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java tests SocketChannel's socket adaptor. Two of tests, testTimedRead1 and testTimedRead2 have relatively short timeouts which can cause the test to fail if the VM is paused or the machine is hung/overloaded for more than a few seconds. I've changed the timeout used by the two tests to 60s. This change does not impact the duration of the test because the reads do not timeout. In passing, I've changed testTimedRead3 to use a timeout of 500ms, it is expected to throw SocketTimeoutException, and replaced setSoTimeout(60*1000) with setSoTimeout(60_000) in several other tests. ------------- Commit messages: - Bump timeout for tests that don't expect SocketTimeoutException Changes: https://git.openjdk.java.net/jdk/pull/6351/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6351&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276763 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/6351.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6351/head:pull/6351 PR: https://git.openjdk.java.net/jdk/pull/6351 From itakiguchi at openjdk.java.net Thu Nov 11 14:13:32 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 11 Nov 2021 14:13:32 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v2] In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 19:38:01 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Emit a warning on unsupported jnu encoding I applied same kind of patch into jdk17u. The situation was same. $ env LC_ALL=kk_KZ.pt154 ./build/linux-x86_64-server-release/images/jdk/bin/java -showversion Hello.java WARNING: The encoding of the underlying platform's file system is not supported by the JVM: PT154 openjdk version "17.0.1-internal" 2021-10-19 OpenJDK Runtime Environment (build 17.0.1-internal+0-adhoc.jdktest.jdk17u) OpenJDK 64-Bit Server VM (build 17.0.1-internal+0-adhoc.jdktest.jdk17u, mixed mode, sharing) Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.util.ServiceConfigurationError: java.nio.charset.spi.CharsetProvider: Unable to load sun.nio.cs.ext.ExtendedCharsets at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586) ... ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From lancea at openjdk.java.net Thu Nov 11 17:08:48 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 11 Nov 2021 17:08:48 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp Message-ID: Hi, This patch addresses the issue where the very large temp files are not cleaned up after the testMoreThanTwoGB completes. Best Lance ------------- Commit messages: - Fix for JDK-8276994 Changes: https://git.openjdk.java.net/jdk/pull/6360/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6360&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276994 Stats: 28 lines in 1 file changed: 11 ins; 6 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/6360.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6360/head:pull/6360 PR: https://git.openjdk.java.net/jdk/pull/6360 From alanb at openjdk.java.net Thu Nov 11 17:15:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 11 Nov 2021 17:15:39 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 17:01:48 GMT, Lance Andersen wrote: > Hi, > > This patch addresses the issue where the very large temp files are not cleaned up after the testMoreThanTwoGB completes. > > > Best > Lance Thanks for taking this one. I guess it should really be Files.delete as both files do exist, leaving it as deleteIfExists is okay. It's possible that creating targetFile will fail and leave sourceFile behind but it will be an empty file so won't fill up the file system. So I think this is okay as is. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6360 From prappo at openjdk.java.net Thu Nov 11 17:19:37 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 11 Nov 2021 17:19:37 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 17:01:48 GMT, Lance Andersen wrote: > Hi, > > This patch addresses the issue where the very large temp files are not cleaned up after the testMoreThanTwoGB completes. > > > Best > Lance test/jdk/java/nio/channels/Channels/TransferTo.java line 165: > 163: System.out.printf("Cleaning up: %s, %s%n", sourceFile, targetFile); > 164: Files.deleteIfExists(sourceFile); > 165: Files.deleteIfExists(targetFile); What about an exception thrown from `Files.deleteIfExists(sourceFile)` in that `finally` block? ------------- PR: https://git.openjdk.java.net/jdk/pull/6360 From coffeys at openjdk.java.net Thu Nov 11 17:34:40 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 11 Nov 2021 17:34:40 GMT Subject: RFR: 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB [v4] In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 18:37:39 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 one additional commit since the last revision: > > Indentation {code} Path sourceFile = Files.createTempFile(null, null); Path targetFile = Files.createTempFile(null, null); {code} Please also consider putting an identifier on your temp files so that we have a clue to who's creating them (if deletion fails) ------------- PR: https://git.openjdk.java.net/jdk/pull/6093 From coffeys at openjdk.java.net Thu Nov 11 17:57:41 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 11 Nov 2021 17:57:41 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 17:01:48 GMT, Lance Andersen wrote: > Hi, > > This patch addresses the issue where the very large temp files are not cleaned up after the testMoreThanTwoGB completes. > > > Best > Lance test/jdk/java/nio/channels/Channels/TransferTo.java line 143: > 141: // preparing two temporary files which will be compared at the end of the test > 142: Path sourceFile = Files.createTempFile(null, null); > 143: Path targetFile = Files.createTempFile(null, null); can we add an identifier to the tmp files ? In the case where deletion fails, we'll be able to identify the origin more easily. ------------- PR: https://git.openjdk.java.net/jdk/pull/6360 From duke at openjdk.java.net Thu Nov 11 18:04:41 2021 From: duke at openjdk.java.net (Mike Hearn) Date: Thu, 11 Nov 2021 18:04:41 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v5] In-Reply-To: <8ZmwxROZTxe0QOB0umC5CfYN2g_zP5gYOCeRXeBa88c=.98e8288f-0c29-49b0-a620-4877f6995ef3@github.com> References: <8ZmwxROZTxe0QOB0umC5CfYN2g_zP5gYOCeRXeBa88c=.98e8288f-0c29-49b0-a620-4877f6995ef3@github.com> Message-ID: On Wed, 3 Nov 2021 18:46:48 GMT, Brian Burkhalter wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273922: Change getNameCount() != 1 tp getParent() != null > > That would be the third commit, labelled 02 (zero-relative). @bplb That commit seems to have the same problem. Here's a test diff that shows the issue: diff --git a/test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java b/test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java index bc47b8719f2..769de937e7c 100644 --- a/test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java +++ b/test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java @@ -235,9 +235,16 @@ public class Basic { view.read(ATTR_NAME, buf); }}); - // Long attribute name + // Windows has special rules for "long" paths. if (Platform.isWindows()) { Path tmp = Files.createTempDirectory(dir, "ea-length-bug"); + + // Create a file with a path name longer than MAX_PATH. This just verifies no exception is thrown. + Path longFilePath = tmp.resolve("y".repeat(300)); + Files.write(longFilePath, "y".getBytes(StandardCharsets.UTF_8)); + setEA(longFilePath, "user:ea"); + + // Long attribute name. int len = tmp.toString().length(); // We need to run up to MAX_PATH for directories, There's no test that checks EAs work on ordinary long file names. The above shows the failure, because `WindowsPath.createFromNormalizedPath` is called and it doesn't seem to understand the `\?` prefix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From lancea at openjdk.java.net Thu Nov 11 18:12:03 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 11 Nov 2021 18:12:03 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp [v2] In-Reply-To: References: Message-ID: > Hi, > > This patch addresses the issue where the very large temp files are not cleaned up after the testMoreThanTwoGB completes. > > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Additional updates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6360/files - new: https://git.openjdk.java.net/jdk/pull/6360/files/34859e00..60ce3817 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6360&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6360&range=00-01 Stats: 37 lines in 1 file changed: 15 ins; 9 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/6360.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6360/head:pull/6360 PR: https://git.openjdk.java.net/jdk/pull/6360 From alanb at openjdk.java.net Thu Nov 11 18:26:35 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 11 Nov 2021 18:26:35 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp [v2] In-Reply-To: References: Message-ID: <4N53ZR-7RZ12zgydyhGfqH7mAlTzet-U7nFy46hVtNc=.7b98df73-f487-4ddd-85ac-ab00a4524cbe@github.com> On Thu, 11 Nov 2021 18:12:03 GMT, Lance Andersen wrote: >> Hi, >> >> This patch addresses the issue where the very large temp files are not cleaned up after the testMoreThanTwoGB completes. >> >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Additional updates test/jdk/java/nio/channels/Channels/TransferTo.java line 145: > 143: try { > 144: // preparing two temporary files which will be compared at the end of the test > 145: sourceFile = Files.createTempFile("test2GBSource", null); If this throws then Files.delete(sourceFile) will throw an NPE. I think it would be just a bit more robust to initialize sourceFile to Files.createTempFile(...) rather than null. ------------- PR: https://git.openjdk.java.net/jdk/pull/6360 From dfuchs at openjdk.java.net Thu Nov 11 18:41:33 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 11 Nov 2021 18:41:33 GMT Subject: RFR: 8276763: java/nio/channels/SocketChannel/AdaptorStreams.java fails with "SocketTimeoutException: Read timed out" In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 13:53:26 GMT, Alan Bateman wrote: > test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java tests SocketChannel's socket adaptor. Two of tests, testTimedRead1 and testTimedRead2 have relatively short timeouts which can cause the test to fail if the VM is paused or the machine is hung/overloaded for more than a few seconds. I've changed the timeout used by the two tests to 60s. This change does not impact the duration of the test because the reads do not timeout. > > In passing, I've changed testTimedRead3 to use a timeout of 500ms, it is expected to throw SocketTimeoutException, and replaced setSoTimeout(60*1000) with setSoTimeout(60_000) in several other tests. LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6351 From lancea at openjdk.java.net Thu Nov 11 18:44:04 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 11 Nov 2021 18:44:04 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp [v3] In-Reply-To: References: Message-ID: > Hi, > > This patch addresses the issue where the very large temp files are not cleaned up after the testMoreThanTwoGB completes. > > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: tweak initialiation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6360/files - new: https://git.openjdk.java.net/jdk/pull/6360/files/60ce3817..981d008e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6360&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6360&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6360.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6360/head:pull/6360 PR: https://git.openjdk.java.net/jdk/pull/6360 From dfuchs at openjdk.java.net Thu Nov 11 18:47:34 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 11 Nov 2021 18:47:34 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp [v3] In-Reply-To: References: Message-ID: <1ydw3AUPKMdq56K_qkSn_0QINUyye23SJKhqqQqCFf4=.75f1a9dc-eba1-4187-a111-2b85e6e63de8@github.com> On Thu, 11 Nov 2021 17:17:01 GMT, Pavel Rappo wrote: >> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: >> >> tweak initialiation > > test/jdk/java/nio/channels/Channels/TransferTo.java line 165: > >> 163: System.out.printf("Cleaning up: %s, %s%n", sourceFile, targetFile); >> 164: Files.deleteIfExists(sourceFile); >> 165: Files.deleteIfExists(targetFile); > > What about an exception thrown from `Files.deleteIfExists(sourceFile)` in that `finally` block? Right - maybe that should be done in a private method where the exception would be catch'ed and logged (`printStackTrace`) - otherwise an exception in the finally clause risks masking any exception that was thrown before the finally clause was reached. ------------- PR: https://git.openjdk.java.net/jdk/pull/6360 From lancea at openjdk.java.net Thu Nov 11 19:08:06 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 11 Nov 2021 19:08:06 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp [v4] In-Reply-To: References: Message-ID: > Hi, > > This patch addresses the issue where the very large temp files are not cleaned up after the testMoreThanTwoGB completes. > > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Init targe in try ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6360/files - new: https://git.openjdk.java.net/jdk/pull/6360/files/981d008e..236e1a27 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6360&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6360&range=02-03 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6360.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6360/head:pull/6360 PR: https://git.openjdk.java.net/jdk/pull/6360 From alanb at openjdk.java.net Thu Nov 11 19:08:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 11 Nov 2021 19:08:09 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp [v4] In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 19:04:51 GMT, Lance Andersen wrote: >> Hi, >> >> This patch addresses the issue where the very large temp files are not cleaned up after the testMoreThanTwoGB completes. >> >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Init targe in try Thanks for the update, looks much more robust now. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6360 From alanb at openjdk.java.net Thu Nov 11 19:10:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 11 Nov 2021 19:10:46 GMT Subject: Integrated: 8276763: java/nio/channels/SocketChannel/AdaptorStreams.java fails with "SocketTimeoutException: Read timed out" In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 13:53:26 GMT, Alan Bateman wrote: > test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java tests SocketChannel's socket adaptor. Two of tests, testTimedRead1 and testTimedRead2 have relatively short timeouts which can cause the test to fail if the VM is paused or the machine is hung/overloaded for more than a few seconds. I've changed the timeout used by the two tests to 60s. This change does not impact the duration of the test because the reads do not timeout. > > In passing, I've changed testTimedRead3 to use a timeout of 500ms, it is expected to throw SocketTimeoutException, and replaced setSoTimeout(60*1000) with setSoTimeout(60_000) in several other tests. This pull request has now been integrated. Changeset: 8aae88b0 Author: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/8aae88b0fc4acb76ef140f120712403cf4b04a46 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod 8276763: java/nio/channels/SocketChannel/AdaptorStreams.java fails with "SocketTimeoutException: Read timed out" Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/6351 From lancea at openjdk.java.net Thu Nov 11 19:12:40 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 11 Nov 2021 19:12:40 GMT Subject: Integrated: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 17:01:48 GMT, Lance Andersen wrote: > Hi, > > This patch addresses the issue where the very large temp files are not cleaned up after the testMoreThanTwoGB completes. > > > Best > Lance This pull request has now been integrated. Changeset: b0d7a9da Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/b0d7a9daa6ceb1959bc701043fe3f0397d2ba6f7 Stats: 34 lines in 1 file changed: 14 ins; 6 del; 14 mod 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/6360 From mcimadamore at openjdk.java.net Fri Nov 12 11:16:17 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 12 Nov 2021 11:16:17 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v24] 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: Adopt blessed modofier order ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/8c3860f8..79d3d685 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=23 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=22-23 Stats: 7 lines in 6 files changed: 0 ins; 0 del; 7 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 Fri Nov 12 19:11:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 12 Nov 2021 19:11:07 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v3] In-Reply-To: References: Message-ID: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Force the jnu encoding to UTF-8 if the original one is not supported ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6282/files - new: https://git.openjdk.java.net/jdk/pull/6282/files/d3c240c9..c50e6279 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=01-02 Stats: 12 lines in 1 file changed: 8 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6282/head:pull/6282 PR: https://git.openjdk.java.net/jdk/pull/6282 From naoto at openjdk.java.net Fri Nov 12 19:14:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 12 Nov 2021 19:14:40 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v3] In-Reply-To: References: Message-ID: <7SegolhFmkgnaXprWFBgk64bPLXCYaU1A-G-Gxdia4I=.8b7438b4-6904-4405-b1a5-9861c262e646@github.com> On Fri, 12 Nov 2021 19:11:07 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Force the jnu encoding to UTF-8 if the original one is not supported I reproduced those failures on Debian Linux. Corrected the issue by replacing unsupported jnu encoding with `UTF-8` in `System::initPhase1`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Sat Nov 13 19:30:35 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 13 Nov 2021 19:30:35 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v3] In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 19:11:07 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Force the jnu encoding to UTF-8 if the original one is not supported src/java.base/share/classes/java/lang/System.java line 2127: > 2125: props.setProperty("sun.jnu.encoding", "UTF-8"); > 2126: } > 2127: You could replace the two fields with something like "notSupportedJnuEncoding" that is only set when not supported. That keeps the additional code in initPhase1 to a minimum. src/java.base/share/classes/java/lang/System.java line 2267: > 2265: "WARNING: The encoding of the underlying platform's" + > 2266: " file system is not supported by the JVM: %s%n", > 2267: jnuEncoding); I think you can drop "by the JVM" from the warning. Also just to point out that this is running in initPhase3. I'm pretty sure the use of formatters here will execute code that checks VM.isBooted. It might be better to just use string concatenation and avoid loading formatters here. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From naoto at openjdk.java.net Sun Nov 14 00:20:05 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sun, 14 Nov 2021 00:20:05 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v4] In-Reply-To: References: Message-ID: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Eliminated unnecessary static field, formatter utilization. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6282/files - new: https://git.openjdk.java.net/jdk/pull/6282/files/c50e6279..b1b0fd05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=02-03 Stats: 14 lines in 1 file changed: 1 ins; 2 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/6282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6282/head:pull/6282 PR: https://git.openjdk.java.net/jdk/pull/6282 From naoto at openjdk.java.net Sun Nov 14 00:23:35 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sun, 14 Nov 2021 00:23:35 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v3] In-Reply-To: References: Message-ID: On Sat, 13 Nov 2021 19:24:07 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Force the jnu encoding to UTF-8 if the original one is not supported > > src/java.base/share/classes/java/lang/System.java line 2127: > >> 2125: props.setProperty("sun.jnu.encoding", "UTF-8"); >> 2126: } >> 2127: > > You could replace the two fields with something like "notSupportedJnuEncoding" that is only set when not supported. That keeps the additional code in initPhase1 to a minimum. Replaced as suggested. > src/java.base/share/classes/java/lang/System.java line 2267: > >> 2265: "WARNING: The encoding of the underlying platform's" + >> 2266: " file system is not supported by the JVM: %s%n", >> 2267: jnuEncoding); > > I think you can drop "by the JVM" from the warning. > > Also just to point out that this is running in initPhase3. I'm pretty sure the use of formatters here will execute code that checks VM.isBooted. It might be better to just use string concatenation and avoid loading formatters here. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From naoto at openjdk.java.net Sun Nov 14 02:23:03 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sun, 14 Nov 2021 02:23:03 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v5] In-Reply-To: References: Message-ID: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed indentation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6282/files - new: https://git.openjdk.java.net/jdk/pull/6282/files/b1b0fd05..26d79e99 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6282/head:pull/6282 PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Sun Nov 14 07:26:36 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 14 Nov 2021 07:26:36 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v5] In-Reply-To: References: Message-ID: On Sun, 14 Nov 2021 02:23:03 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed indentation src/java.base/share/classes/java/lang/System.java line 2123: > 2121: var jnuEncoding = props.getProperty("sun.jnu.encoding"); > 2122: if (jnuEncoding == null || !Charset.isSupported(jnuEncoding)) { > 2123: notSupportedJnuEncoding = jnuEncoding == null ? "null" : jnuEncoding; I think we are nearly there. When setting notSupportedJnuEncoding then we also need to set the sun.jnu.encoding property to "UTF-8", setting it in initPhase3 is too late because the file system may be used using initPhase2. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From duke at openjdk.java.net Sun Nov 14 09:15:47 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 14 Nov 2021 09:15:47 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp Message-ID: This PR proposes to cleanup *all* temp files of the `TransferTo` test, not just the 2GB files. Also it separates the actual test logic from the cleanup logic, so the test cases are simple to understand again as they are not interwoven with cleanup code anymore. ------------- Commit messages: - Cleaning up temp files Changes: https://git.openjdk.java.net/jdk/pull/6379/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6379&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276994 Stats: 67 lines in 1 file changed: 37 ins; 14 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/6379.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6379/head:pull/6379 PR: https://git.openjdk.java.net/jdk/pull/6379 From duke at openjdk.java.net Sun Nov 14 09:15:48 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 14 Nov 2021 09:15:48 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: On Sat, 13 Nov 2021 21:56:36 GMT, Markus KARG wrote: > This PR proposes to cleanup *all* temp files of the `TransferTo` test, not just the 2GB files. Also it separates the actual test logic from the cleanup logic, so the test cases are simple to understand again as they are not interwoven with cleanup code anymore. @AlanBateman As proposed by my earliert today in the JIRA discussion. WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From lancea at openjdk.java.net Sun Nov 14 11:44:38 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 14 Nov 2021 11:44:38 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: On Sat, 13 Nov 2021 21:56:36 GMT, Markus KARG wrote: > This PR proposes to cleanup *all* temp files of the `TransferTo` test, not just the 2GB files. Also it separates the actual test logic from the cleanup logic, so the test cases are simple to understand again as they are not interwoven with cleanup code anymore. thank you for cleaning up the additional temp files created by this test. Please see comments below. test/jdk/java/nio/channels/Channels/TransferTo.java line 78: > 76: > 77: private static Collection tempFiles; > 78: Is there a reason you chose a LinkedList over a List here? As mentioned below, you could initialize tempFiles here. Please change Collection -> LinkedList or if you use a List to ArrayList() test/jdk/java/nio/channels/Channels/TransferTo.java line 147: > 145: @Test > 146: public void testMoreThanTwoGB() throws IOException { > 147: // preparing two temporary files which will be compared at the end of the test I would prefer to keep the previous changes to this test. We went through a few iterations off line. We would also prefer to delete these files at the end of the test, not just the over all test run due to their size. test/jdk/java/nio/channels/Channels/TransferTo.java line 285: > 283: @BeforeClass > 284: public static void createTempFileRegistry() { > 285: tempFiles = new LinkedList(); This could be initialized as part of the declaration. test/jdk/java/nio/channels/Channels/TransferTo.java line 303: > 301: * Creates a temporary file and registers it for later cleanup after tests. > 302: */ > 303: private static Path newTempFile() throws IOException { You might consider passing in the prefix to make it easier to differentiate the temp file (InputStreamProvider vs OutputSteamProvider...) ------------- Changes requested by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6379 From naoto at openjdk.java.net Sun Nov 14 14:44:59 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sun, 14 Nov 2021 14:44:59 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v6] In-Reply-To: References: Message-ID: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Move UTF-8 fallback up into initPhase1() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6282/files - new: https://git.openjdk.java.net/jdk/pull/6282/files/26d79e99..3428cdf4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=04-05 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6282/head:pull/6282 PR: https://git.openjdk.java.net/jdk/pull/6282 From naoto at openjdk.java.net Sun Nov 14 14:45:00 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sun, 14 Nov 2021 14:45:00 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v5] In-Reply-To: References: Message-ID: On Sun, 14 Nov 2021 07:23:18 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed indentation > > src/java.base/share/classes/java/lang/System.java line 2123: > >> 2121: var jnuEncoding = props.getProperty("sun.jnu.encoding"); >> 2122: if (jnuEncoding == null || !Charset.isSupported(jnuEncoding)) { >> 2123: notSupportedJnuEncoding = jnuEncoding == null ? "null" : jnuEncoding; > > I think we are nearly there. When setting notSupportedJnuEncoding then we also need to set the sun.jnu.encoding property to "UTF-8", setting it in initPhase3 is too late because the file system may be used using initPhase2. Initially, I thought that was the case, but I mistook your suggestion as setting only `notSupportedJnuEncoding` in initPhase1. Reverted the fallback location into `initPhase1()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From duke at openjdk.java.net Sun Nov 14 14:47:37 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 14 Nov 2021 14:47:37 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: <9ymWYkP8CxDCuRV7-U-KnlnOU3Up4_4kzILhBrYJpb0=.e5ce5b6b-db9f-4c24-9022-55009c943ad3@github.com> On Sun, 14 Nov 2021 11:32:27 GMT, Lance Andersen wrote: >> This PR proposes to cleanup *all* temp files of the `TransferTo` test, not just the 2GB files. Also it separates the actual test logic from the cleanup logic, so the test cases are simple to understand again as they are not interwoven with cleanup code anymore. > > test/jdk/java/nio/channels/Channels/TransferTo.java line 78: > >> 76: >> 77: private static Collection tempFiles; >> 78: > > Is there a reason you chose a LinkedList over a List here? As mentioned below, you could initialize tempFiles here. > > Please change Collection -> LinkedList or if you use a List initialize with an ArrayList() If you change from an interface to a particular implementation you give the reader the impression that the code will only work with this particular implementation, and you give the impression that the code will only work in a particular sequence when using List or LinkedList, which both is not true. The Collection interface was chosen deliberately to clearly tell the reader that both is completely irrelevant and may be changed at any time if needed. If I do what you want, others will fear to break something. So i would like to stay with the code as-is. > test/jdk/java/nio/channels/Channels/TransferTo.java line 147: > >> 145: @Test >> 146: public void testMoreThanTwoGB() throws IOException { >> 147: // preparing two temporary files which will be compared at the end of the test > > I would prefer to keep the previous changes to this test. We went through a few iterations off line. We would also prefer to delete these files at the end of the test, not just the over all test run due to their size. As all the *other* tests in this test class run rather quick (within seconds) I wonder what you expect to *actually* gain? The difference would just be some seconds of earlier deletion for the sake of worse readability, actually. If the majority is for keeping your original solution, this is fine for me. I just like to understand the driver behind this. > test/jdk/java/nio/channels/Channels/TransferTo.java line 285: > >> 283: @BeforeClass >> 284: public static void createTempFileRegistry() { >> 285: tempFiles = new LinkedList(); > > This could be initialized as part of the declaration. Yes I could do that but I think it is better to understand for the reader as it clearly explains that this code is part of the test management, not part of the test logic. > test/jdk/java/nio/channels/Channels/TransferTo.java line 303: > >> 301: * Creates a temporary file and registers it for later cleanup after tests. >> 302: */ >> 303: private static Path newTempFile() throws IOException { > > You might consider passing in the prefix to make it easier to differentiate the temp file (InputStreamProvider vs OutputSteamProvider...) Is this really worth the extra complexity? What is the use case where this plays a vital role? ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From duke at openjdk.java.net Sun Nov 14 14:47:37 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 14 Nov 2021 14:47:37 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: <9ymWYkP8CxDCuRV7-U-KnlnOU3Up4_4kzILhBrYJpb0=.e5ce5b6b-db9f-4c24-9022-55009c943ad3@github.com> References: <9ymWYkP8CxDCuRV7-U-KnlnOU3Up4_4kzILhBrYJpb0=.e5ce5b6b-db9f-4c24-9022-55009c943ad3@github.com> Message-ID: On Sun, 14 Nov 2021 14:43:00 GMT, Markus KARG wrote: >> test/jdk/java/nio/channels/Channels/TransferTo.java line 78: >> >>> 76: >>> 77: private static Collection tempFiles; >>> 78: >> >> Is there a reason you chose a LinkedList over a List here? As mentioned below, you could initialize tempFiles here. >> >> Please change Collection -> LinkedList or if you use a List initialize with an ArrayList() > > If you change from an interface to a particular implementation you give the reader the impression that the code will only work with this particular implementation, and you give the impression that the code will only work in a particular sequence when using List or LinkedList, which both is not true. The Collection interface was chosen deliberately to clearly tell the reader that both is completely irrelevant and may be changed at any time if needed. If I do what you want, others will fear to break something. So i would like to stay with the code as-is. What *actual* benefit will you reach in this *particular* source code by using array list instead of linked list? ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From alanb at openjdk.java.net Sun Nov 14 14:51:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 14 Nov 2021 14:51:42 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v6] In-Reply-To: References: Message-ID: On Sun, 14 Nov 2021 14:44:59 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Move UTF-8 fallback up into initPhase1() Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Sun Nov 14 14:51:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 14 Nov 2021 14:51:42 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v5] In-Reply-To: References: Message-ID: On Sun, 14 Nov 2021 14:41:21 GMT, Naoto Sato wrote: > Initially, I thought that was the case, but I mistook your suggestion as setting only `notSupportedJnuEncoding` in initPhase1. Reverted the fallback location into `initPhase1()`. np, it's always tricky to touch code that executes early in the startup. I think we are good now. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From lancea at openjdk.java.net Sun Nov 14 14:58:30 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 14 Nov 2021 14:58:30 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: <9ymWYkP8CxDCuRV7-U-KnlnOU3Up4_4kzILhBrYJpb0=.e5ce5b6b-db9f-4c24-9022-55009c943ad3@github.com> Message-ID: On Sun, 14 Nov 2021 14:43:50 GMT, Markus KARG wrote: >> If you change from an interface to a particular implementation you give the reader the impression that the code will only work with this particular implementation, and you give the impression that the code will only work in a particular sequence when using List or LinkedList, which both is not true. The Collection interface was chosen deliberately to clearly tell the reader that both is completely irrelevant and may be changed at any time if needed. If I do what you want, others will fear to break something. So i would like to stay with the code as-is. > > What *actual* benefit will you reach in this *particular* source code by using array list instead of linked list? There is really no need to use a LinkedList so the use of a List is just simpler. ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From lancea at openjdk.java.net Sun Nov 14 14:58:31 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 14 Nov 2021 14:58:31 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: <9ymWYkP8CxDCuRV7-U-KnlnOU3Up4_4kzILhBrYJpb0=.e5ce5b6b-db9f-4c24-9022-55009c943ad3@github.com> References: <9ymWYkP8CxDCuRV7-U-KnlnOU3Up4_4kzILhBrYJpb0=.e5ce5b6b-db9f-4c24-9022-55009c943ad3@github.com> Message-ID: <8YPQfexMpzQSojif_NGTi99VQG3fqBSr6jlJ7_-M4kI=.2b3b3398-091b-4bf4-af4e-65a002d7d7b9@github.com> On Sun, 14 Nov 2021 14:40:15 GMT, Markus KARG wrote: >> test/jdk/java/nio/channels/Channels/TransferTo.java line 285: >> >>> 283: @BeforeClass >>> 284: public static void createTempFileRegistry() { >>> 285: tempFiles = new LinkedList(); >> >> This could be initialized as part of the declaration. > > Yes I could do that but I think it is better to understand for the reader as it clearly explains that this code is part of the test management, not part of the test logic. This is a simple test so really no need not do the initialization as part of the declaration given there is no other work done by this method. ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From lancea at openjdk.java.net Sun Nov 14 15:11:39 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 14 Nov 2021 15:11:39 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: <9ymWYkP8CxDCuRV7-U-KnlnOU3Up4_4kzILhBrYJpb0=.e5ce5b6b-db9f-4c24-9022-55009c943ad3@github.com> References: <9ymWYkP8CxDCuRV7-U-KnlnOU3Up4_4kzILhBrYJpb0=.e5ce5b6b-db9f-4c24-9022-55009c943ad3@github.com> Message-ID: On Sun, 14 Nov 2021 14:38:46 GMT, Markus KARG wrote: >> test/jdk/java/nio/channels/Channels/TransferTo.java line 147: >> >>> 145: @Test >>> 146: public void testMoreThanTwoGB() throws IOException { >>> 147: // preparing two temporary files which will be compared at the end of the test >> >> I would prefer to keep the previous changes to this test. We went through a few iterations off line. We would also prefer to delete these files at the end of the test, not just the over all test run due to their size. > > As all the *other* tests in this test class run rather quick (within seconds) I wonder what you expect to *actually* gain? The difference would just be some seconds of earlier deletion for the sake of worse readability, actually. If the majority is for keeping your original solution, this is fine for me. I just like to understand the driver behind this. In the unlikely event there is an error, we can uniquely identify which file is left around more easily. Your proposed change ignores the IOException completely. Given the size of the files, best to clean up before existing the test method. ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From alanb at openjdk.java.net Sun Nov 14 16:11:31 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 14 Nov 2021 16:11:31 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: On Sat, 13 Nov 2021 21:56:36 GMT, Markus KARG wrote: > This PR proposes to cleanup *all* temp files of the `TransferTo` test, not just the 2GB files. Also it separates the actual test logic from the cleanup logic, so the test cases are simple to understand again as they are not interwoven with cleanup code anymore. I think we need this. Instead, it would be better if the tests uses the test work directory so the files are easily found for post failure analysis. This isn't practical for the tests that create >2GB files so I think leave the code that Lance put in there to delete them so they aren't archived when the work directory is zipped up. ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From duke at openjdk.java.net Sun Nov 14 17:03:38 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 14 Nov 2021 17:03:38 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: <9ymWYkP8CxDCuRV7-U-KnlnOU3Up4_4kzILhBrYJpb0=.e5ce5b6b-db9f-4c24-9022-55009c943ad3@github.com> Message-ID: On Sun, 14 Nov 2021 14:53:32 GMT, Lance Andersen wrote: >> What *actual* benefit will you reach in this *particular* source code by using array list instead of linked list? > > There is really no need to use a LinkedList so the use of a List is just simpler. There also is no need to use an ArrayList, so how does you answer explain your request? ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From duke at openjdk.java.net Sun Nov 14 17:03:39 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 14 Nov 2021 17:03:39 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: <9ymWYkP8CxDCuRV7-U-KnlnOU3Up4_4kzILhBrYJpb0=.e5ce5b6b-db9f-4c24-9022-55009c943ad3@github.com> Message-ID: <1HeCPKTcBeozYrgRzJag_Vz9PB5MLZLItpxKgTNWwtc=.eba7421c-2a28-4a4a-86c2-556028803e3e@github.com> On Sun, 14 Nov 2021 15:08:35 GMT, Lance Andersen wrote: >> As all the *other* tests in this test class run rather quick (within seconds) I wonder what you expect to *actually* gain? The difference would just be some seconds of earlier deletion for the sake of worse readability, actually. If the majority is for keeping your original solution, this is fine for me. I just like to understand the driver behind this. > > In the unlikely event there is an error, we can uniquely identify which file is left around more easily. Your proposed change ignores the IOException completely. > > Given the size of the files, best to clean up before existing the test method. What should it be good for knowing which test left behind the temp file? As the code is not incorrect, you always would just delete *all* temp files of this test anyways - whether they are from the 2GB test or not. So this information helps you exactly nothing. Your original code also ignored the IOException completely, so I do not understand that argument. I do not see *any* benefit from immediate deletion vs deletion after ten seconds. Those arguments are rather academic. I miss *real* benefit, actually. >> Yes I could do that but I think it is better to understand for the reader as it clearly explains that this code is part of the test management, not part of the test logic. > > This is a simple test so really no need not do the initialization as part of the declaration given there is no other work done by this method. As I explained, this is not written due to a *need* but due to *deliberate separation of concerns*. So is separation of concerns a design strategy that is forbidden in OpenJDK? ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From duke at openjdk.java.net Sun Nov 14 17:06:40 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 14 Nov 2021 17:06:40 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: On Sun, 14 Nov 2021 16:08:57 GMT, Alan Bateman wrote: > I don't think we need this. @AlanBateman @LanceAndersen You are confusing me. Lance requests style changes, while Alan does not want the changes. These answers are incompatible. *Either* I change the code according Lance's wishes, *or* we simple drop this PR. Please find a concensus. ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From itakiguchi at openjdk.java.net Mon Nov 15 02:43:48 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 15 Nov 2021 02:43:48 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v3] In-Reply-To: <7SegolhFmkgnaXprWFBgk64bPLXCYaU1A-G-Gxdia4I=.8b7438b4-6904-4405-b1a5-9861c262e646@github.com> References: <7SegolhFmkgnaXprWFBgk64bPLXCYaU1A-G-Gxdia4I=.8b7438b4-6904-4405-b1a5-9861c262e646@github.com> Message-ID: On Fri, 12 Nov 2021 19:11:16 GMT, Naoto Sato wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Force the jnu encoding to UTF-8 if the original one is not supported > > I reproduced those failures on Debian Linux. Corrected the issue by replacing unsupported jnu encoding with `UTF-8` in `System::initPhase1`. @naotoj , sorry for bothering you again. Still I got exception. It seems value "jnuEncoding" should be overwritten or set "fastEncoding" to "FAST_UTF_8" on jnu_util.c. Could you check this part again ? $ env LC_ALL=kk_KZ.pt154 ./build/linux-x86_64-server-release/images/jdk/bin/java Hello.java WARNING: The encoding of the underlying platform's file system is not supported: PT154 Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.util.ServiceConfigurationError: java.nio.charset.spi.CharsetProvider: Provider sun.nio.cs.ext.ExtendedCharsets not found at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593) at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:875) at java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.hasNext(ServiceLoader.java:1084) at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309) at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393) at java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:428) at java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:422) at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) at java.base/java.nio.charset.Charset$ExtendedProviderHolder.extendedProviders(Charset.java:422) at java.base/java.nio.charset.Charset$ExtendedProviderHolder.(Charset.java:418) at java.base/java.nio.charset.Charset.lookupExtendedCharset(Charset.java:442) at java.base/java.nio.charset.Charset.lookup2(Charset.java:472) at java.base/java.nio.charset.Charset.lookup(Charset.java:460) at java.base/java.nio.charset.Charset.isSupported(Charset.java:501) at java.base/jdk.internal.loader.NativeLibraries.findBuiltinLib(Native Method) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:157) at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:322) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:289) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:274) at java.base/jdk.internal.loader.BootLoader.loadLibrary(BootLoader.java:149) at java.base/sun.nio.fs.UnixNativeDispatcher.(UnixNativeDispatcher.java:667) at java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:65) at java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46) at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39) at java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider.java:55) at java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvider.java:41) at java.base/sun.nio.fs.DefaultFileSystemProvider.(DefaultFileSystemProvider.java:35) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:114) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:103) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:101) at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:101) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:94) at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:183) at java.base/java.nio.file.Path.of(Path.java:147) at java.base/java.nio.file.Paths.get(Paths.java:69) at java.base/jdk.internal.jimage.ImageReaderFactory.(ImageReaderFactory.java:51) at java.base/jdk.internal.module.SystemModuleFinders$SystemImage.(SystemModuleFinders.java:385) at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.findImageLocation(SystemModuleFinders.java:429) at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.read(SystemModuleFinders.java:483) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:809) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741) at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:633) at java.base/java.lang.Class.forName(Class.java:577) at java.base/java.lang.Class.forName(Class.java:552) at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:748) at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:683) ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Mon Nov 15 07:42:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 15 Nov 2021 07:42:40 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: On Sun, 14 Nov 2021 16:08:57 GMT, Alan Bateman wrote: >> This PR proposes to cleanup *all* temp files of the `TransferTo` test, not just the 2GB files. Also it separates the actual test logic from the cleanup logic, so the test cases are simple to understand again as they are not interwoven with cleanup code anymore. > > I don't think we need this. Instead, it would be better if the tests uses the test work directory so the files are easily found for post failure analysis. This isn't practical for the tests that create >2GB files so I think leave the code that Lance put in there to delete them so they aren't archived when the work directory is zipped up. > @AlanBateman @LanceAndersen You are confusing me. Lance requests style changes, while Alan does not want the changes. These answers are incompatible. _Either_ I change the code according Lance's wishes, _or_ we simple drop this PR. Please find a concensus. I think it's better to pause a moment and understand the environment when jtreg runs tests. The important thing is that the current directory (as in user.dir) will be a scratch directory that jtreg has created. My comments are just pointing out that the bookkeeping proposed in this PR to delete files is not needed that you can just change the test to create the temp file in the current directory. We can leave the try-finally that Lance added in the >2GB tests because they are too big to keep for any post failure analysis. ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From naoto at openjdk.java.net Mon Nov 15 17:32:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 15 Nov 2021 17:32:07 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v3] In-Reply-To: References: <7SegolhFmkgnaXprWFBgk64bPLXCYaU1A-G-Gxdia4I=.8b7438b4-6904-4405-b1a5-9861c262e646@github.com> Message-ID: On Mon, 15 Nov 2021 02:40:14 GMT, Ichiroh Takiguchi wrote: >> I reproduced those failures on Debian Linux. Corrected the issue by replacing unsupported jnu encoding with `UTF-8` in `System::initPhase1`. > > @naotoj , sorry for bothering you again. > Still I got exception. It seems value "jnuEncoding" should be overwritten or set "fastEncoding" to "FAST_UTF_8" on jnu_util.c. > Could you check this part again ? > > $ env LC_ALL=kk_KZ.pt154 ./build/linux-x86_64-server-release/images/jdk/bin/java Hello.java > WARNING: The encoding of the underlying platform's file system is not supported: PT154 > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.util.ServiceConfigurationError: java.nio.charset.spi.CharsetProvider: Provider sun.nio.cs.ext.ExtendedCharsets not found > at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593) > at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:875) > at java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.hasNext(ServiceLoader.java:1084) > at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309) > at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393) > at java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:428) > at java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:422) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) > at java.base/java.nio.charset.Charset$ExtendedProviderHolder.extendedProviders(Charset.java:422) > at java.base/java.nio.charset.Charset$ExtendedProviderHolder.(Charset.java:418) > at java.base/java.nio.charset.Charset.lookupExtendedCharset(Charset.java:442) > at java.base/java.nio.charset.Charset.lookup2(Charset.java:472) > at java.base/java.nio.charset.Charset.lookup(Charset.java:460) > at java.base/java.nio.charset.Charset.isSupported(Charset.java:501) > at java.base/jdk.internal.loader.NativeLibraries.findBuiltinLib(Native Method) > at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:157) > at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:322) > at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:289) > at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:274) > at java.base/jdk.internal.loader.BootLoader.loadLibrary(BootLoader.java:149) > at java.base/sun.nio.fs.UnixNativeDispatcher.(UnixNativeDispatcher.java:667) > at java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:65) > at java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) > at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46) > at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39) > at java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider.java:55) > at java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvider.java:41) > at java.base/sun.nio.fs.DefaultFileSystemProvider.(DefaultFileSystemProvider.java:35) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:114) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:103) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:101) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:101) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:94) > at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:183) > at java.base/java.nio.file.Path.of(Path.java:147) > at java.base/java.nio.file.Paths.get(Paths.java:69) > at java.base/jdk.internal.jimage.ImageReaderFactory.(ImageReaderFactory.java:51) > at java.base/jdk.internal.module.SystemModuleFinders$SystemImage.(SystemModuleFinders.java:385) > at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.findImageLocation(SystemModuleFinders.java:429) > at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.read(SystemModuleFinders.java:483) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:809) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:633) > at java.base/java.lang.Class.forName(Class.java:577) > at java.base/java.lang.Class.forName(Class.java:552) > at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:748) > at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:683) Fallback to UTF-8 in jni_uti.c::InitializeEncoding() as well, if the jnu encoding is not supported. @takiguc, would you try the changeset on your environment? ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From naoto at openjdk.java.net Mon Nov 15 17:32:04 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 15 Nov 2021 17:32:04 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v7] In-Reply-To: References: Message-ID: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Replace jnuEncoding in jni_util.c with UTF-8, if platform encoding is not supported ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6282/files - new: https://git.openjdk.java.net/jdk/pull/6282/files/3428cdf4..c241e8da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=05-06 Stats: 70 lines in 1 file changed: 20 ins; 37 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/6282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6282/head:pull/6282 PR: https://git.openjdk.java.net/jdk/pull/6282 From dfuchs at openjdk.java.net Mon Nov 15 18:01:37 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 15 Nov 2021 18:01:37 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: <1HeCPKTcBeozYrgRzJag_Vz9PB5MLZLItpxKgTNWwtc=.eba7421c-2a28-4a4a-86c2-556028803e3e@github.com> References: <9ymWYkP8CxDCuRV7-U-KnlnOU3Up4_4kzILhBrYJpb0=.e5ce5b6b-db9f-4c24-9022-55009c943ad3@github.com> <1HeCPKTcBeozYrgRzJag_Vz9PB5MLZLItpxKgTNWwtc=.eba7421c-2a28-4a4a-86c2-556028803e3e@github.com> Message-ID: On Sun, 14 Nov 2021 16:59:58 GMT, Markus KARG wrote: >> This is a simple test so really no need not do the initialization as part of the declaration given there is no other work done by this method. > > As I explained, this is not written due to a *need* but due to *deliberate separation of concerns*. So is separation of concerns a design strategy that is forbidden in OpenJDK? It's better to avoid using raw-types unless there's a specific reason to do so (I guess this is just an oversight). ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From akasko at openjdk.java.net Mon Nov 15 22:31:02 2021 From: akasko at openjdk.java.net (Alex Kasko) Date: Mon, 15 Nov 2021 22:31:02 GMT Subject: RFR: 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points Message-ID: <_3lqAz9mpWcTrbpOQlrfAO340unv6D8SWy5vSKEZEQo=.f86c4818-d4d6-4f6a-aa38-975f19fa3e31@github.com> ?/user/* mount points The fix to the test is the same as in #5136 . The possible problem with this test was identified in [this comment](https://github.com/openjdk/jdk/pull/5136#issuecomment-900402107), however FileSystemException is thrown instead of NoSuchFileException in this case, thus the special check for "/run/user" is added. ------------- Commit messages: - 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points Changes: https://git.openjdk.java.net/jdk/pull/6399/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6399&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277159 Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6399/head:pull/6399 PR: https://git.openjdk.java.net/jdk/pull/6399 From itakiguchi at openjdk.java.net Tue Nov 16 02:20:37 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Tue, 16 Nov 2021 02:20:37 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v3] In-Reply-To: References: <7SegolhFmkgnaXprWFBgk64bPLXCYaU1A-G-Gxdia4I=.8b7438b4-6904-4405-b1a5-9861c262e646@github.com> Message-ID: On Mon, 15 Nov 2021 17:28:44 GMT, Naoto Sato wrote: >> @naotoj , sorry for bothering you again. >> Still I got exception. It seems value "jnuEncoding" should be overwritten or set "fastEncoding" to "FAST_UTF_8" on jnu_util.c. >> Could you check this part again ? >> >> $ env LC_ALL=kk_KZ.pt154 ./build/linux-x86_64-server-release/images/jdk/bin/java Hello.java >> WARNING: The encoding of the underlying platform's file system is not supported: PT154 >> Error: A JNI error has occurred, please check your installation and try again >> Exception in thread "main" java.util.ServiceConfigurationError: java.nio.charset.spi.CharsetProvider: Provider sun.nio.cs.ext.ExtendedCharsets not found >> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593) >> at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:875) >> at java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.hasNext(ServiceLoader.java:1084) >> at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309) >> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393) >> at java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:428) >> at java.base/java.nio.charset.Charset$ExtendedProviderHolder$1.run(Charset.java:422) >> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) >> at java.base/java.nio.charset.Charset$ExtendedProviderHolder.extendedProviders(Charset.java:422) >> at java.base/java.nio.charset.Charset$ExtendedProviderHolder.(Charset.java:418) >> at java.base/java.nio.charset.Charset.lookupExtendedCharset(Charset.java:442) >> at java.base/java.nio.charset.Charset.lookup2(Charset.java:472) >> at java.base/java.nio.charset.Charset.lookup(Charset.java:460) >> at java.base/java.nio.charset.Charset.isSupported(Charset.java:501) >> at java.base/jdk.internal.loader.NativeLibraries.findBuiltinLib(Native Method) >> at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:157) >> at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:322) >> at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:289) >> at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:274) >> at java.base/jdk.internal.loader.BootLoader.loadLibrary(BootLoader.java:149) >> at java.base/sun.nio.fs.UnixNativeDispatcher.(UnixNativeDispatcher.java:667) >> at java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:65) >> at java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) >> at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46) >> at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39) >> at java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider.java:55) >> at java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvider.java:41) >> at java.base/sun.nio.fs.DefaultFileSystemProvider.(DefaultFileSystemProvider.java:35) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:114) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:103) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:101) >> at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:101) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:94) >> at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:183) >> at java.base/java.nio.file.Path.of(Path.java:147) >> at java.base/java.nio.file.Paths.get(Paths.java:69) >> at java.base/jdk.internal.jimage.ImageReaderFactory.(ImageReaderFactory.java:51) >> at java.base/jdk.internal.module.SystemModuleFinders$SystemImage.(SystemModuleFinders.java:385) >> at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.findImageLocation(SystemModuleFinders.java:429) >> at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.read(SystemModuleFinders.java:483) >> at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:809) >> at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741) >> at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:633) >> at java.base/java.lang.Class.forName(Class.java:577) >> at java.base/java.lang.Class.forName(Class.java:552) >> at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:748) >> at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:683) > > Fallback to UTF-8 in jni_uti.c::InitializeEncoding() as well, if the jnu encoding is not supported. @takiguc, would you try the changeset on your environment? Hello @naotoj . Test results are as follows: $ env LC_ALL=kk_KZ.pt154 ./build/linux-x86_64-server-release/images/jdk/bin/java Hello.java WARNING: The encoding of the underlying platform's file system is not supported: PT154 Hello $ env LC_ALL=kk_KZ.pt154 ./build/linux-x86_64-server-release/images/jdk/bin/java -XshowSettings:properties Hello.java 2>&1 | grep encoding WARNING: The encoding of the underlying platform's file system is not supported: PT154 file.encoding = UTF-8 native.encoding = PT154 sun.io.unicode.encoding = UnicodeLittle sun.jnu.encoding = UTF-8 $ env LC_ALL=kk_KZ.pt154 ./build/linux-x86_64-server-release/images/jdk/bin/java -Dfile.encoding=COMPAT Hello.java WARNING: The encoding of the underlying platform's file system is not supported: PT154 Hello $ env LC_ALL=kk_KZ.pt154 ./build/linux-x86_64-server-release/images/jdk/bin/java -XshowSettings:properties -Dfile.encoding=COMPAT Hello.java 2>&1 | grep encoding WARNING: The encoding of the underlying platform's file system is not supported: PT154 file.encoding = PT154 native.encoding = PT154 sun.io.unicode.encoding = UnicodeLittle sun.jnu.encoding = UTF-8 $ ./build/linux-x86_64-server-release/images/jdk/bin/java Hello.java Hello $ ./build/linux-x86_64-server-release/images/jdk/bin/java -XshowSettings:properties Hello.java 2>&1 | grep encoding file.encoding = UTF-8 native.encoding = UTF-8 sun.io.unicode.encoding = UnicodeLittle sun.jnu.encoding = UTF-8 These were what I expected. Many thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From duke at openjdk.java.net Tue Nov 16 18:26:37 2021 From: duke at openjdk.java.net (Markus KARG) Date: Tue, 16 Nov 2021 18:26:37 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v12] In-Reply-To: References: <9nZAJMsgmswOzPH7LRNACzAXNlUJJhq0lw0ZNMXd21U=.ada29744-bd87-4c41-a9ce-b926ab0988ef@github.com> Message-ID: On Thu, 11 Nov 2021 11:57:07 GMT, Alan Bateman wrote: >> The corresponding CSR can be found here: https://bugs.openjdk.java.net/browse/JDK-8276968 > >> The corresponding CSR can be found here: https://bugs.openjdk.java.net/browse/JDK-8276968 > > Thanks. I've re-worked the wording to trim it down and put it a style that is more consistent with other CSRs. If you are okay it then press "Finalize" on the CSR to finalize it. @AlanBateman It seems the CSR was approved. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From bpb at openjdk.java.net Tue Nov 16 21:58:36 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 16 Nov 2021 21:58:36 GMT Subject: RFR: 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points In-Reply-To: <_3lqAz9mpWcTrbpOQlrfAO340unv6D8SWy5vSKEZEQo=.f86c4818-d4d6-4f6a-aa38-975f19fa3e31@github.com> References: <_3lqAz9mpWcTrbpOQlrfAO340unv6D8SWy5vSKEZEQo=.f86c4818-d4d6-4f6a-aa38-975f19fa3e31@github.com> Message-ID: On Mon, 15 Nov 2021 22:20:44 GMT, Alex Kasko wrote: > ?/user/* mount points > > The fix to the test is the same as in #5136 . The possible problem with this test was identified in [this comment](https://github.com/openjdk/jdk/pull/5136#issuecomment-900402107), however FileSystemException is thrown instead of NoSuchFileException in this case, thus the special check for "/run/user" is added. test/jdk/java/nio/file/FileStore/Basic.java line 25: > 23: > 24: /* @test > 25: * @bug 4313887 6873621 6979526 7006126 7020517 8264400 8277159 I don't think that the bug ID needs to be added here as this is a change to the test itself, only. ------------- PR: https://git.openjdk.java.net/jdk/pull/6399 From akasko at openjdk.java.net Wed Nov 17 12:55:10 2021 From: akasko at openjdk.java.net (Alex Kasko) Date: Wed, 17 Nov 2021 12:55:10 GMT Subject: RFR: 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points [v2] In-Reply-To: <_3lqAz9mpWcTrbpOQlrfAO340unv6D8SWy5vSKEZEQo=.f86c4818-d4d6-4f6a-aa38-975f19fa3e31@github.com> References: <_3lqAz9mpWcTrbpOQlrfAO340unv6D8SWy5vSKEZEQo=.f86c4818-d4d6-4f6a-aa38-975f19fa3e31@github.com> Message-ID: > ?/user/* mount points > > The fix to the test is the same as in #5136 . The possible problem with this test was identified in [this comment](https://github.com/openjdk/jdk/pull/5136#issuecomment-900402107), however FileSystemException is thrown instead of NoSuchFileException in this case, thus the special check for "/run/user" is added. Alex Kasko has updated the pull request incrementally with one additional commit since the last revision: remove bug id ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6399/files - new: https://git.openjdk.java.net/jdk/pull/6399/files/7c112e3c..f4c9973d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6399&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6399&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6399/head:pull/6399 PR: https://git.openjdk.java.net/jdk/pull/6399 From akasko at openjdk.java.net Wed Nov 17 12:55:15 2021 From: akasko at openjdk.java.net (Alex Kasko) Date: Wed, 17 Nov 2021 12:55:15 GMT Subject: RFR: 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points [v2] In-Reply-To: References: <_3lqAz9mpWcTrbpOQlrfAO340unv6D8SWy5vSKEZEQo=.f86c4818-d4d6-4f6a-aa38-975f19fa3e31@github.com> Message-ID: On Tue, 16 Nov 2021 21:55:29 GMT, Brian Burkhalter wrote: >> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision: >> >> remove bug id > > test/jdk/java/nio/file/FileStore/Basic.java line 25: > >> 23: >> 24: /* @test >> 25: * @bug 4313887 6873621 6979526 7006126 7020517 8264400 8277159 > > I don't think that the bug ID needs to be added here as this is a change to the test itself, only. Thanks for your comments! I've removed the bug ID. ------------- PR: https://git.openjdk.java.net/jdk/pull/6399 From alanb at openjdk.java.net Wed Nov 17 13:05:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 17 Nov 2021 13:05:43 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v7] In-Reply-To: References: Message-ID: <6gl0S2zmvWpb0gdXzJayRM8CnTCdyGGcgTRRDRowaso=.443d8f3e-f345-4e21-8272-2a513baf8f6e@github.com> On Mon, 15 Nov 2021 17:32:04 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Replace jnuEncoding in jni_util.c with UTF-8, if platform encoding is not supported src/java.base/share/classes/sun/nio/fs/Util.java line 43: > 41: Charset.forName( > 42: GetPropertyAction.privilegedGetProperty("sun.jnu.encoding"), > 43: sun.nio.cs.UTF_8.INSTANCE); Startup will ensure that sun.jnu.encoding has a value that is a supported encoding so I assume the the fallback in sun.nio.ch.Util is no longer needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Wed Nov 17 14:32:36 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 17 Nov 2021 14:32:36 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v7] In-Reply-To: References: Message-ID: <5ujG2GpRGEyz6-cV96iAOsosmSMXLGWoenVzNK-fX2Y=.5a8fdae2-f35b-4015-a809-7bb8e17c6082@github.com> On Mon, 15 Nov 2021 17:32:04 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Replace jnuEncoding in jni_util.c with UTF-8, if platform encoding is not supported src/java.base/share/native/libjava/jni_util.c line 825: > 823: } > 824: (*env)->GetByteArrayRegion(env, hab, 0, len, (jbyte *)result); > 825: result[len] = 0; /* NULL-terminate */ The change to newSizedStringJava is okay but I think the change to getStringBytes needs more eyes. Will it fall through to the code path sets it to FAST_UTF_8 during startup or does that happen later? If later then I assume there is a race with other threads that read jnuEncoding and potential for the JNI global ref to be freed from under their feet. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From bpb at openjdk.java.net Wed Nov 17 17:07:38 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Nov 2021 17:07:38 GMT Subject: RFR: 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points [v2] In-Reply-To: References: <_3lqAz9mpWcTrbpOQlrfAO340unv6D8SWy5vSKEZEQo=.f86c4818-d4d6-4f6a-aa38-975f19fa3e31@github.com> Message-ID: On Wed, 17 Nov 2021 12:55:10 GMT, Alex Kasko wrote: >> ?/user/* mount points >> >> The fix to the test is the same as in #5136 . The possible problem with this test was identified in [this comment](https://github.com/openjdk/jdk/pull/5136#issuecomment-900402107), however FileSystemException is thrown instead of NoSuchFileException in this case, thus the special check for "/run/user" is added. > > Alex Kasko has updated the pull request incrementally with one additional commit since the last revision: > > remove bug id Passed 5 test repeats on Linux, macOS, and Windows. Approved. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6399 From akasko at openjdk.java.net Wed Nov 17 17:28:14 2021 From: akasko at openjdk.java.net (Alex Kasko) Date: Wed, 17 Nov 2021 17:28:14 GMT Subject: RFR: 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points [v2] In-Reply-To: References: <_3lqAz9mpWcTrbpOQlrfAO340unv6D8SWy5vSKEZEQo=.f86c4818-d4d6-4f6a-aa38-975f19fa3e31@github.com> Message-ID: <3ogbnVg7h_vEqwULmCeuN71Xp0sYm_NEi35dtWUGkmw=.856c969e-10f4-4751-beed-fdb54820bc67@github.com> On Wed, 17 Nov 2021 12:55:10 GMT, Alex Kasko wrote: >> ?/user/* mount points >> >> The fix to the test is the same as in #5136 . The possible problem with this test was identified in [this comment](https://github.com/openjdk/jdk/pull/5136#issuecomment-900402107), however FileSystemException is thrown instead of NoSuchFileException in this case, thus the special check for "/run/user" is added. > > Alex Kasko has updated the pull request incrementally with one additional commit since the last revision: > > remove bug id Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/6399 From shade at openjdk.java.net Wed Nov 17 17:36:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 17 Nov 2021 17:36:02 GMT Subject: RFR: 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points [v2] In-Reply-To: References: <_3lqAz9mpWcTrbpOQlrfAO340unv6D8SWy5vSKEZEQo=.f86c4818-d4d6-4f6a-aa38-975f19fa3e31@github.com> Message-ID: On Wed, 17 Nov 2021 12:55:10 GMT, Alex Kasko wrote: >> ?/user/* mount points >> >> The fix to the test is the same as in #5136 . The possible problem with this test was identified in [this comment](https://github.com/openjdk/jdk/pull/5136#issuecomment-900402107), however FileSystemException is thrown instead of NoSuchFileException in this case, thus the special check for "/run/user" is added. > > Alex Kasko has updated the pull request incrementally with one additional commit since the last revision: > > remove bug id Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6399 From naoto at openjdk.java.net Wed Nov 17 17:48:39 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 17 Nov 2021 17:48:39 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v8] In-Reply-To: References: Message-ID: <_-RIVTJCa3cUkOuw9R0K8tFiLF5MhzjduBK0-zIBfLI=.acda1ca0-f83a-43c7-87e7-352c88974d9c@github.com> > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed changes to Util.java as it is not needed. Eliminated premature jnuEncoding initializaiton in jni_util.c::InitializeEncoding() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6282/files - new: https://git.openjdk.java.net/jdk/pull/6282/files/c241e8da..5681ba74 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6282&range=06-07 Stats: 17 lines in 2 files changed: 6 ins; 7 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6282.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6282/head:pull/6282 PR: https://git.openjdk.java.net/jdk/pull/6282 From akasko at openjdk.java.net Wed Nov 17 17:51:56 2021 From: akasko at openjdk.java.net (Alex Kasko) Date: Wed, 17 Nov 2021 17:51:56 GMT Subject: Integrated: 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points In-Reply-To: <_3lqAz9mpWcTrbpOQlrfAO340unv6D8SWy5vSKEZEQo=.f86c4818-d4d6-4f6a-aa38-975f19fa3e31@github.com> References: <_3lqAz9mpWcTrbpOQlrfAO340unv6D8SWy5vSKEZEQo=.f86c4818-d4d6-4f6a-aa38-975f19fa3e31@github.com> Message-ID: <-Z84pgpyJQKAYeID15VL58J4Ze8_wS6x7t56tl6LkTA=.4abad97e-db6c-46a4-8886-898982e8df45@github.com> On Mon, 15 Nov 2021 22:20:44 GMT, Alex Kasko wrote: > ?/user/* mount points > > The fix to the test is the same as in #5136 . The possible problem with this test was identified in [this comment](https://github.com/openjdk/jdk/pull/5136#issuecomment-900402107), however FileSystemException is thrown instead of NoSuchFileException in this case, thus the special check for "/run/user" is added. This pull request has now been integrated. Changeset: b6876649 Author: Alex Kasko Committer: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/b6876649a82bed508d817ccbde1600d00937e4b2 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points Reviewed-by: bpb, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/6399 From naoto at openjdk.java.net Wed Nov 17 17:52:33 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 17 Nov 2021 17:52:33 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v7] In-Reply-To: <6gl0S2zmvWpb0gdXzJayRM8CnTCdyGGcgTRRDRowaso=.443d8f3e-f345-4e21-8272-2a513baf8f6e@github.com> References: <6gl0S2zmvWpb0gdXzJayRM8CnTCdyGGcgTRRDRowaso=.443d8f3e-f345-4e21-8272-2a513baf8f6e@github.com> Message-ID: On Wed, 17 Nov 2021 13:02:10 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace jnuEncoding in jni_util.c with UTF-8, if platform encoding is not supported > > src/java.base/share/classes/sun/nio/fs/Util.java line 43: > >> 41: Charset.forName( >> 42: GetPropertyAction.privilegedGetProperty("sun.jnu.encoding"), >> 43: sun.nio.cs.UTF_8.INSTANCE); > > Startup will ensure that sun.jnu.encoding has a value that is a supported encoding so I assume the the fallback in sun.nio.ch.Util is no longer needed. Reverted the fix. > src/java.base/share/native/libjava/jni_util.c line 825: > >> 823: } >> 824: (*env)->GetByteArrayRegion(env, hab, 0, len, (jbyte *)result); >> 825: result[len] = 0; /* NULL-terminate */ > > The change to newSizedStringJava is okay but I think the change to getStringBytes needs more eyes. Will it fall through to the code path sets it to FAST_UTF_8 during startup or does that happen later? If later then I assume there is a race with other threads that read jnuEncoding and potential for the JNI global ref to be freed from under their feet. Good point. Removed the premature `jnuEncoding` initialization in `InitializeEncoding()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From alanb at openjdk.java.net Wed Nov 17 18:55:44 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 17 Nov 2021 18:55:44 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v8] In-Reply-To: <_-RIVTJCa3cUkOuw9R0K8tFiLF5MhzjduBK0-zIBfLI=.acda1ca0-f83a-43c7-87e7-352c88974d9c@github.com> References: <_-RIVTJCa3cUkOuw9R0K8tFiLF5MhzjduBK0-zIBfLI=.acda1ca0-f83a-43c7-87e7-352c88974d9c@github.com> Message-ID: On Wed, 17 Nov 2021 17:48:39 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed changes to Util.java as it is not needed. > Eliminated premature jnuEncoding initializaiton in jni_util.c::InitializeEncoding() Thanks for the update, the latest version looks good. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6282 From iris at openjdk.java.net Wed Nov 17 19:14:44 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 17 Nov 2021 19:14:44 GMT Subject: RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales [v8] In-Reply-To: <_-RIVTJCa3cUkOuw9R0K8tFiLF5MhzjduBK0-zIBfLI=.acda1ca0-f83a-43c7-87e7-352c88974d9c@github.com> References: <_-RIVTJCa3cUkOuw9R0K8tFiLF5MhzjduBK0-zIBfLI=.acda1ca0-f83a-43c7-87e7-352c88974d9c@github.com> Message-ID: On Wed, 17 Nov 2021 17:48:39 GMT, Naoto Sato wrote: >> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed changes to Util.java as it is not needed. > Eliminated premature jnuEncoding initializaiton in jni_util.c::InitializeEncoding() Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From bpb at openjdk.java.net Wed Nov 17 19:37:07 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Nov 2021 19:37:07 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) Message-ID: Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. ------------- Commit messages: - 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) Changes: https://git.openjdk.java.net/jdk/pull/6435/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6435&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276661 Stats: 32 lines in 3 files changed: 23 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6435/head:pull/6435 PR: https://git.openjdk.java.net/jdk/pull/6435 From bpb at openjdk.java.net Wed Nov 17 19:37:08 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Nov 2021 19:37:08 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 19:28:19 GMT, Brian Burkhalter wrote: > Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. The test fails without the proposed implementation change but passes with the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/6435 From alanb at openjdk.java.net Wed Nov 17 20:01:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 17 Nov 2021 20:01:51 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v12] In-Reply-To: References: <9nZAJMsgmswOzPH7LRNACzAXNlUJJhq0lw0ZNMXd21U=.ada29744-bd87-4c41-a9ce-b926ab0988ef@github.com> Message-ID: On Thu, 11 Nov 2021 11:57:07 GMT, Alan Bateman wrote: >> The corresponding CSR can be found here: https://bugs.openjdk.java.net/browse/JDK-8276968 > >> The corresponding CSR can be found here: https://bugs.openjdk.java.net/browse/JDK-8276968 > > Thanks. I've re-worked the wording to trim it down and put it a style that is more consistent with other CSRs. If you are okay it then press "Finalize" on the CSR to finalize it. > @AlanBateman It seems the CSR was approved. :-) Yes, I think we are nearly done. As the spec/impl is to throw IllegalBlockingModeException when the channel is non-blocking then it would be good to have the test exercise that case. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From alanb at openjdk.java.net Wed Nov 17 20:17:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 17 Nov 2021 20:17:43 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 19:28:19 GMT, Brian Burkhalter wrote: > Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 185: > 183: > 184: String getPathForWin32Calls(boolean alwaysAddPrefix) > 185: throws WindowsException { Minor nit, can you move the "throws WindowsException {" to the previous line. src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 313: > 311: if (!path.startsWith("\\\\")) { > 312: path = "\\\\?\\" + path; > 313: } I think the approach looks okay but I wonder if we need to handle the UNC case here. ------------- PR: https://git.openjdk.java.net/jdk/pull/6435 From naoto at openjdk.java.net Thu Nov 18 01:16:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 18 Nov 2021 01:16:41 GMT Subject: Integrated: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 17:31:50 GMT, Naoto Sato wrote: > Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported. This pull request has now been integrated. Changeset: b8453ebd Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/b8453ebdb471e08cc8d62c777f33ad52902f67d7 Stats: 106 lines in 2 files changed: 43 ins; 45 del; 18 mod 8275007: Java fails to start with null charset if LC_ALL is set to certain locales Reviewed-by: rriggs, iris, joehw, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/6282 From bpb at openjdk.java.net Thu Nov 18 04:32:17 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Nov 2021 04:32:17 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v2] In-Reply-To: References: Message-ID: > Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8276661: Support UNC paths ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6435/files - new: https://git.openjdk.java.net/jdk/pull/6435/files/4e7c265b..f817c36a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6435&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6435&range=00-01 Stats: 29 lines in 2 files changed: 15 ins; 1 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/6435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6435/head:pull/6435 PR: https://git.openjdk.java.net/jdk/pull/6435 From bpb at openjdk.java.net Thu Nov 18 04:32:22 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Nov 2021 04:32:22 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v2] In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 20:14:07 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8276661: Support UNC paths > > src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 185: > >> 183: >> 184: String getPathForWin32Calls(boolean alwaysAddPrefix) >> 185: throws WindowsException { > > Minor nit, can you move the "throws WindowsException {" to the previous line. Fixed. > src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 313: > >> 311: if (!path.startsWith("\\\\")) { >> 312: path = "\\\\?\\" + path; >> 313: } > > I think the approach looks okay but I wonder if we need to handle the UNC case here. Addressed in commit 01. ------------- PR: https://git.openjdk.java.net/jdk/pull/6435 From bpb at openjdk.java.net Thu Nov 18 04:34:37 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Nov 2021 04:34:37 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 19:28:19 GMT, Brian Burkhalter wrote: > Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. The test passes locally but has some problem when run in the CI and fails with a message like this: Exception: java.nio.file.FileSystemException: \\\\localhost\\t$\\testoutput\\test-support\\jtreg_open_test_jdk_java_nio_file_attribute_UserDefinedFileAttributeView_Basic_java\\tmp\\name12001724450276850194\\ea-length-bug17788303373605884510\\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: The network name cannot be found ------------- PR: https://git.openjdk.java.net/jdk/pull/6435 From alanb at openjdk.java.net Thu Nov 18 08:36:48 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 18 Nov 2021 08:36:48 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v2] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 04:28:48 GMT, Brian Burkhalter wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 313: >> >>> 311: if (!path.startsWith("\\\\")) { >>> 312: path = "\\\\?\\" + path; >>> 313: } >> >> I think the approach looks okay but I wonder if we need to handle the UNC case here. > > Addressed in commit 01. It would be a lot simpler to just add "addPrefix" that unconditionally adds the prefix. There should be no scenario where double translation happens, if it does then there's a bug and I'm concerned that addPrefixIfAbsent will mask it. ------------- PR: https://git.openjdk.java.net/jdk/pull/6435 From bchristi at openjdk.java.net Thu Nov 18 22:55:02 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Thu, 18 Nov 2021 22:55:02 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal Message-ID: Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. The CSR has been approved. An automated test build+test run passes cleanly (FWIW :D ). ------------- Commit messages: - merge - @SuppressWarnings(removal) in Windows CKey.java - Add jls tag to runFinalization methods - Update wording of Object.finalize, new paragraph is now bold - update Object.finalize javadoc - update Object.finalize JavaDoc and @deprecated tag - Update Object.finalize deprecation message - Indicate that runFinalizers does nothing if finalization is disabled or removed - Fix @since on @Deprecated for java.lang.Enum - Clarify conditions for removal of Object.finalize method - ... and 21 more: https://git.openjdk.java.net/jdk/compare/89b125f4...eca95cb2 Changes: https://git.openjdk.java.net/jdk/pull/6465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276447 Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/6465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465 PR: https://git.openjdk.java.net/jdk/pull/6465 From bpb at openjdk.java.net Fri Nov 19 02:13:14 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 19 Nov 2021 02:13:14 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v3] In-Reply-To: References: Message-ID: > Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8276661: Replace addPrefixIfAbsent() with addPrefix() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6435/files - new: https://git.openjdk.java.net/jdk/pull/6435/files/f817c36a..bf5e3dcd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6435&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6435&range=01-02 Stats: 60 lines in 2 files changed: 20 ins; 22 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/6435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6435/head:pull/6435 PR: https://git.openjdk.java.net/jdk/pull/6435 From bpb at openjdk.java.net Fri Nov 19 02:16:47 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 19 Nov 2021 02:16:47 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 08:33:48 GMT, Alan Bateman wrote: >> Addressed in commit 01. > > It would be a lot simpler to just add "addPrefix" that unconditionally adds the prefix. There should be no scenario where double translation happens, if it does then there's a bug and I'm concerned that addPrefixIfAbsent will mask it. Updated in commit 02. ------------- PR: https://git.openjdk.java.net/jdk/pull/6435 From jai.forums2013 at gmail.com Fri Nov 19 11:40:25 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 19 Nov 2021 17:10:25 +0530 Subject: Seeking inputs on 8224794: ZipFile/JarFile should open zip/JAR file with FILE_SHARE_DELETE sharing mode on Windows Message-ID: I have been experimenting with https://bugs.openjdk.java.net/browse/JDK-8224794 and have reached a stage with my changes where I would like some inputs before I move ahead or raise a PR for review. As noted in that JBS issue, the idea is to open the underlying file using FILE_SHARE_DELETE when using java.uitl.zip.ZipFile and java.util.jar.JarFile. From what I can infer from that JBS issue, the motivation behind this seems to be to allow deleting that underlying file when that file is currently opened and in use by the ZipFile/JarFile instance. The linked github issues seem to suggest the same. IMO, it's a reasonable expectation, given that such a deletion works on *nix platform. It's on Windows where such a deletion fails with "The process cannot access the file because it is being used by another process" (the other process in many cases will be the current JVM instance itself). So trying to get this to work on Windows by setting the FILE_SHARE_DELETE share access mode seems reasonable. Coming to the implementation part, I've an initial draft version here https://github.com/openjdk/jdk/pull/6477. It sets the FILE_SHARE_DELETE share access mode on the file when constructed by ZipFile/JarFile. It "works", in the sense that if you issue a delete against this underlying file (path) after its been opened by ZipFile/JarFile instance, you no longer see the error mentioned above and the delete completes without any exception. However, my experiments with this change have raised a bunch of questions related to this: The crucial part of the "DeleteFile" API in Windows is that, as stated in its documentation[1]: "The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED." So imagine the following pseudo-code: String path = "C:/foo.jar" 1. JarFile jar = new JarFile(path); // create a jar instance 2. var deleted = new File(path).delete(); // delete the underlying file 3. var exists = new File(path).exists(); // check file existence 4. FileOutputStream fos = new FileOutputStream(new File(path)); // open a FileOutputStream for /tmp/foo.jar 5. java.nio.file.Files.deleteIfExists(Path.of(path)); When this is run (on Windows) *without* the change that introduces FILE_SHARE_DELETE, I notice that line#2 returns "false" for File.delete() (since the file is in use by the JarFile instance) and then line#3 returns "true" since it still exists and line#4 succeeds and creates a new FileOutputStream and line#5 fails with an exception stating "java.nio.file.FileSystemException: foo.jar: The process cannot access the file because it is being used by another process " Now when the same code is run (on Windows) *with* the proposed FILE_SHARE_DELETE changes, I notice that line#2 returns "true" (i.e. the file is considered deleted) and line#3 returns "true" (i.e. it's considered the file still exists). So essentially the file is only marked for deletion and hasn't been deleted at the OS level, since the JarFile instance still has an handle open. Then line#4 unlike previously, now throws an exception and fails to create the FileOutputStream instance. The failure says "java.nio.file.AccessDeniedException: foo.jar". This exception matches the documentation from that Windows DeleteFile API. line#5 too fails with this same AccessDeniedException. So what this means is, although we have managed to allow the deletion to happen (i.e. the first call to delete does mark it for deletion at OS level), IMO, it still doesn't improve much and raises other difference in behaviour of APIs as seen above, unless the underlying file handle held by ZipFile/JarFile is closed. So that brings me to the next related issue. For this change to be really useful, the file handle (which is an instance of RandomAccessFile) held by ZipFile/JarFile needs to be closed. If a user application explicitly creates an instance of ZipFile/JarFile, it is expected that they close it themselves. However, the most prominent use of the JarFile creation is within the JDK code where it uses the sun.net.www.protocol.jar.JarURLConnection to construct the JarFile instances, typically from the URLClassLoader. By default these JarFile instances that are created by the sun.net.www.protocol.jar.JarURLConnection are cached and the close() on those instances is called only when the URLClassLoader is close()ed. That in itself doesn't guarantee that the underlying file descriptor corresponding to the JarFile instance gets closed, because there's one more level of reference counting "cache" in use in java.util.zip.ZipFile$Source class where the same underlying file descriptor (corresponding to the jar file) gets used by multiple JarFile instances (irrespective of who created those). So in short, the underlying file descriptor of a JarFile only gets closed when every single instance of a JarFile pointing to the same jar file has been close()ed within the JVM. Which effectively means that introducing the FILE_SHARE_DELETE semantics/changes for Windows will only allow the first delete() attempt to succeed (since that one marks it for deletion), but any subsequent operations like the one noted in the examples, that rely on that file being deleted will continue to fail with Access Denied errors. Given all this caching of JarFile and the reference count cache for the underlying jar file, is this change of FILE_SHARE_DELETE adding much value and should I pursue it further? [1] https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-deletefilew -Jaikiran From alanb at openjdk.java.net Fri Nov 19 14:14:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 19 Nov 2021 14:14:38 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v3] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 02:13:14 GMT, Brian Burkhalter wrote: >> Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8276661: Replace addPrefixIfAbsent() with addPrefix() src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 304: > 302: // Add long path prefix to path if required > 303: static String addPrefixIfNeeded(String path) { > 304: if (path.length() > MAX_PATH) { We can change addPrefixIfNeeded to call addPrefix for long path. That would avoid duplicate the code to add the prefix. test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java line 258: > 256: String host = java.net.InetAddress.getLocalHost().getHostName(); > 257: String uncName = "\\\\" + host + "\\" + elts[0] + "$" + elts[1]; > 258: Path uncPath = Path.of(uncName); We might have to skip testing UNCs because it will be hard-to-impossible to be reliable in all environments. ------------- PR: https://git.openjdk.java.net/jdk/pull/6435 From rriggs at openjdk.java.net Fri Nov 19 17:31:47 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 19 Nov 2021 17:31:47 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6465 From alanb at openjdk.java.net Fri Nov 19 17:31:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 19 Nov 2021 17:31:53 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Looks good. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6465 From bpb at openjdk.java.net Fri Nov 19 17:32:34 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 19 Nov 2021 17:32:34 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v4] In-Reply-To: References: Message-ID: > Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8276661: addPrefixIfNeeded calls addPrefix; remove UNC test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6435/files - new: https://git.openjdk.java.net/jdk/pull/6435/files/bf5e3dcd..aecffaf9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6435&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6435&range=02-03 Stats: 29 lines in 2 files changed: 0 ins; 15 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6435/head:pull/6435 PR: https://git.openjdk.java.net/jdk/pull/6435 From lancea at openjdk.java.net Fri Nov 19 17:47:57 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 19 Nov 2021 17:47:57 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From alanb at openjdk.java.net Fri Nov 19 17:52:19 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 19 Nov 2021 17:52:19 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v4] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 17:32:34 GMT, Brian Burkhalter wrote: >> Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8276661: addPrefixIfNeeded calls addPrefix; remove UNC test Thanks for the updates. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6435 From darcy at openjdk.java.net Fri Nov 19 18:10:08 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 19 Nov 2021 18:10:08 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From mchung at openjdk.java.net Fri Nov 19 18:10:09 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 19 Nov 2021 18:10:09 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). src/java.base/share/classes/java/lang/Object.java line 481: > 479: * system resources or to perform other cleanup. > 480: *

      > 481: * When running in a Java virtual machine in which finalization has been Disabling finalization is not part of the Java SE spec. This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From bchristi at openjdk.java.net Fri Nov 19 18:19:10 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 19 Nov 2021 18:19:10 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com> On Fri, 19 Nov 2021 18:06:39 GMT, Mandy Chung wrote: >> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. >> >> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. >> >> The CSR has been approved. >> An automated test build+test run passes cleanly (FWIW :D ). > > src/java.base/share/classes/java/lang/Object.java line 481: > >> 479: * system resources or to perform other cleanup. >> 480: *

      >> 481: * When running in a Java virtual machine in which finalization has been > > Disabling finalization is not part of the Java SE spec. This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc. The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal. That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS. ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From mchung at openjdk.java.net Fri Nov 19 19:10:11 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 19 Nov 2021 19:10:11 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From mchung at openjdk.java.net Fri Nov 19 19:10:12 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 19 Nov 2021 19:10:12 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com> References: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com> Message-ID: On Fri, 19 Nov 2021 18:15:46 GMT, Brent Christian wrote: >> src/java.base/share/classes/java/lang/Object.java line 481: >> >>> 479: * system resources or to perform other cleanup. >>> 480: *

      >>> 481: * When running in a Java virtual machine in which finalization has been >> >> Disabling finalization is not part of the Java SE spec. This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc. > > The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal. That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS. Thanks for pointing out that the CSR for JDK-8276422 ("Add command-line option to disable finalization") includes the change of the SE Platform Spec and JLS to allow an implementation for finalization to be disabled. This makes senses now. ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From serb at openjdk.java.net Fri Nov 19 20:16:12 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 19 Nov 2021 20:16:12 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From duke at openjdk.java.net Sat Nov 20 18:42:44 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 20 Nov 2021 18:42:44 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v13] In-Reply-To: References: Message-ID: > 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). > > **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Tests IllegalBlockingModeException Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5179/files - new: https://git.openjdk.java.net/jdk/pull/5179/files/fcf616e2..6c9c50c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=11-12 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5179/head:pull/5179 PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sat Nov 20 18:42:45 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 20 Nov 2021 18:42:45 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v12] In-Reply-To: References: <9nZAJMsgmswOzPH7LRNACzAXNlUJJhq0lw0ZNMXd21U=.ada29744-bd87-4c41-a9ce-b926ab0988ef@github.com> Message-ID: On Wed, 17 Nov 2021 19:58:18 GMT, Alan Bateman wrote: > As the spec/impl is to throw IllegalBlockingModeException when the channel is non-blocking then it would be good to have the test exercise that case. Done in https://github.com/openjdk/jdk/pull/5179/commits/6c9c50c53eda840de79f3fa19219264bf6d55453. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sat Nov 20 18:59:50 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 20 Nov 2021 18:59:50 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: References: Message-ID: > 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). > > **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). 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 one new commit since the last revision: Tests IllegalBlockingModeException Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5179/files - new: https://git.openjdk.java.net/jdk/pull/5179/files/6c9c50c5..2c0d2aea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=12-13 Stats: 12 lines in 1 file changed: 9 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5179/head:pull/5179 PR: https://git.openjdk.java.net/jdk/pull/5179 From alanb at openjdk.java.net Sun Nov 21 08:36:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 21 Nov 2021 08:36:07 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: References: Message-ID: On Sat, 20 Nov 2021 18:59:50 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). >> >> **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). > > 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. test/jdk/java/nio/channels/Channels/TransferTo.java line 198: > 196: > 197: // IllegalBlockingMode must be thrown when trying to perform a transfer > 198: assertThrows(IllegalBlockingModeException.class, () -> is2.transferTo(os2)); Thanks for adding this test. It looks like it leaks 5 file descriptors (the FileChannel, and the source/sink of two pipes). Can you update these to close the channels? The test current runs in othervm mode but if it is changed back to agentvm mode then leaving channels open could impact tests that are run later in the same VM. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sun Nov 21 09:54:33 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 21 Nov 2021 09:54:33 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v15] In-Reply-To: References: Message-ID: > 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). > > **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Closing all claimed resources Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5179/files - new: https://git.openjdk.java.net/jdk/pull/5179/files/2c0d2aea..26ed670b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=13-14 Stats: 18 lines in 1 file changed: 2 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5179/head:pull/5179 PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sun Nov 21 09:57:08 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 21 Nov 2021 09:57:08 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: References: Message-ID: On Sun, 21 Nov 2021 08:32:49 GMT, Alan Bateman wrote: >> 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. > > test/jdk/java/nio/channels/Channels/TransferTo.java line 198: > >> 196: >> 197: // IllegalBlockingMode must be thrown when trying to perform a transfer >> 198: assertThrows(IllegalBlockingModeException.class, () -> is2.transferTo(os2)); > > Thanks for adding this test. It looks like it leaks 5 file descriptors (the FileChannel, and the source/sink of two pipes). Can you update these to close the channels? The test current runs in othervm mode but if it is changed back to agentvm mode then leaving channels open could impact tests that are run later in the same VM. I sketched a possibly solution in https://github.com/openjdk/jdk/pull/5179/commits/26ed670be318669edf1ef9a7101c1136273f2b82, but looking at the PipeImpl internals I doubt that *all* file descriptors actually get closed. To me it feels like this being actually a design flaw of PipeImpl: If one side of a pipe was never actually claimed then it should not keep a descriptor open. So IMHO the final solution would be to file a PR for PipeImpl which either defers opening of the file descriptors until they are claimed (which I doubt would be easily possible), or which cleans up both sides if as soon as one side is closed and the other side never got claimed (which is my personal preference). ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From alanb at openjdk.java.net Sun Nov 21 15:16:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 21 Nov 2021 15:16:08 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: <6FNVAZuVseu_fq0n2k9HBp55F3CZy9RKNd4-nGK2Ytg=.151c2d83-e072-4414-aa05-308e63b3b530@github.com> References: <6FNVAZuVseu_fq0n2k9HBp55F3CZy9RKNd4-nGK2Ytg=.151c2d83-e072-4414-aa05-308e63b3b530@github.com> Message-ID: On Sun, 21 Nov 2021 15:11:55 GMT, Alan Bateman wrote: >> I sketched a possibly solution in https://github.com/openjdk/jdk/pull/5179/commits/26ed670be318669edf1ef9a7101c1136273f2b82, but looking at the PipeImpl internals I doubt that *all* file descriptors actually get closed. To me it feels like this being actually a design flaw of PipeImpl: If one side of a pipe was never actually claimed then it should not keep a descriptor open. So IMHO the final solution would be to file a PR for PipeImpl which either defers opening of the file descriptors until they are claimed (which I doubt would be easily possible), or which cleans up both sides if as soon as one side is closed and the other side never got claimed (which is my personal preference). > >> I sketched a possibly solution in [26ed670](https://github.com/openjdk/jdk/commit/26ed670be318669edf1ef9a7101c1136273f2b82), but looking at the PipeImpl internals I doubt that _all_ file descriptors actually get closed. To me it feels like this being actually a design flaw of PipeImpl: > > A Pipe creates a pair of channels. If you change to something the following then it will fix the issue: > > > Pipe pipe = Pipe.open(); > try { > : > } finally { > pipe.source().close(); > pipe.sink().close(); > } BTW: Would it possible to sync up your loom, it looks like hasn't been updated for some time. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From alanb at openjdk.java.net Sun Nov 21 15:16:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 21 Nov 2021 15:16:08 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: References: Message-ID: <6FNVAZuVseu_fq0n2k9HBp55F3CZy9RKNd4-nGK2Ytg=.151c2d83-e072-4414-aa05-308e63b3b530@github.com> On Sun, 21 Nov 2021 09:54:11 GMT, Markus KARG wrote: >> test/jdk/java/nio/channels/Channels/TransferTo.java line 198: >> >>> 196: >>> 197: // IllegalBlockingMode must be thrown when trying to perform a transfer >>> 198: assertThrows(IllegalBlockingModeException.class, () -> is2.transferTo(os2)); >> >> Thanks for adding this test. It looks like it leaks 5 file descriptors (the FileChannel, and the source/sink of two pipes). Can you update these to close the channels? The test current runs in othervm mode but if it is changed back to agentvm mode then leaving channels open could impact tests that are run later in the same VM. > > I sketched a possibly solution in https://github.com/openjdk/jdk/pull/5179/commits/26ed670be318669edf1ef9a7101c1136273f2b82, but looking at the PipeImpl internals I doubt that *all* file descriptors actually get closed. To me it feels like this being actually a design flaw of PipeImpl: If one side of a pipe was never actually claimed then it should not keep a descriptor open. So IMHO the final solution would be to file a PR for PipeImpl which either defers opening of the file descriptors until they are claimed (which I doubt would be easily possible), or which cleans up both sides if as soon as one side is closed and the other side never got claimed (which is my personal preference). > I sketched a possibly solution in [26ed670](https://github.com/openjdk/jdk/commit/26ed670be318669edf1ef9a7101c1136273f2b82), but looking at the PipeImpl internals I doubt that _all_ file descriptors actually get closed. To me it feels like this being actually a design flaw of PipeImpl: A Pipe creates a pair of channels. If you change to something the following then it will fix the issue: Pipe pipe = Pipe.open(); try { : } finally { pipe.source().close(); pipe.sink().close(); } ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sun Nov 21 17:51:22 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 21 Nov 2021 17:51:22 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v16] In-Reply-To: References: Message-ID: > 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). > > **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Closing non-claimed resourced Signed-off-by: Markus Karg - Closing all claimed resources Signed-off-by: Markus Karg - Tests IllegalBlockingModeException Signed-off-by: Markus Karg - JavaDoc proposal by Alan Bateman - 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo() This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferTo(WritableByteChannel), including special treatment of SelectableByteChannel. Signed-off-by: Markus Karg ------------- Changes: https://git.openjdk.java.net/jdk/pull/5179/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=15 Stats: 104 lines in 3 files changed: 97 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5179/head:pull/5179 PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sun Nov 21 17:51:23 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 21 Nov 2021 17:51:23 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: References: <6FNVAZuVseu_fq0n2k9HBp55F3CZy9RKNd4-nGK2Ytg=.151c2d83-e072-4414-aa05-308e63b3b530@github.com> Message-ID: On Sun, 21 Nov 2021 15:12:46 GMT, Alan Bateman wrote: >>> I sketched a possibly solution in [26ed670](https://github.com/openjdk/jdk/commit/26ed670be318669edf1ef9a7101c1136273f2b82), but looking at the PipeImpl internals I doubt that _all_ file descriptors actually get closed. To me it feels like this being actually a design flaw of PipeImpl: >> >> A Pipe creates a pair of channels. If you change to something the following then it will fix the issue: >> >> >> Pipe pipe = Pipe.open(); >> try { >> : >> } finally { >> pipe.source().close(); >> pipe.sink().close(); >> } > > BTW: Would it possible to sync up your loom, it looks like hasn't been updated for some time. > A Pipe creates a pair of channels. If you change to something the following then it will fix the issue: Sure, I know. Did that in https://github.com/openjdk/jdk/pull/5179/commits/c4904cac46ab07355f0f21327c6909366c897b21. What I actually meant is: This is not apparent to the average Javadoc reader, so I propose to change PipeImpl to not run into this situation instead of asking all calling code to care for that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sun Nov 21 17:51:23 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 21 Nov 2021 17:51:23 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: References: <6FNVAZuVseu_fq0n2k9HBp55F3CZy9RKNd4-nGK2Ytg=.151c2d83-e072-4414-aa05-308e63b3b530@github.com> Message-ID: <5X8_BszkVYY_b9mpfgBE5jCFm7M4rH24dlOUpNi19Gs=.2b33fadf-8b63-4208-ba97-c3281c4a65ca@github.com> On Sun, 21 Nov 2021 17:44:33 GMT, Markus KARG wrote: >> BTW: Would it possible to sync up your loom, it looks like hasn't been updated for some time. > >> A Pipe creates a pair of channels. If you change to something the following then it will fix the issue: > > Sure, I know. Did that in https://github.com/openjdk/jdk/pull/5179/commits/c4904cac46ab07355f0f21327c6909366c897b21. > > What I actually meant is: This is not apparent to the average Javadoc reader, so I propose to change PipeImpl to not run into this situation instead of asking all calling code to care for that. >BTW: Would it possible to sync up your loom, it looks like hasn't been updated for some time. Uhm... syncing *what*? ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From alanb at openjdk.java.net Sun Nov 21 19:21:05 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 21 Nov 2021 19:21:05 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: <5X8_BszkVYY_b9mpfgBE5jCFm7M4rH24dlOUpNi19Gs=.2b33fadf-8b63-4208-ba97-c3281c4a65ca@github.com> References: <6FNVAZuVseu_fq0n2k9HBp55F3CZy9RKNd4-nGK2Ytg=.151c2d83-e072-4414-aa05-308e63b3b530@github.com> <5X8_BszkVYY_b9mpfgBE5jCFm7M4rH24dlOUpNi19Gs=.2b33fadf-8b63-4208-ba97-c3281c4a65ca@github.com> Message-ID: On Sun, 21 Nov 2021 17:46:05 GMT, Markus KARG wrote: >>> A Pipe creates a pair of channels. If you change to something the following then it will fix the issue: >> >> Sure, I know. Did that in https://github.com/openjdk/jdk/pull/5179/commits/c4904cac46ab07355f0f21327c6909366c897b21. >> >> What I actually meant is: This is not apparent to the average Javadoc reader, so I propose to change PipeImpl to not run into this situation instead of asking all calling code to care for that. > >>BTW: Would it possible to sync up your loom, it looks like hasn't been updated for some time. > > Uhm... syncing *what*? > Uhm... syncing _what_? There was a typo, sorry. I meant your repo as the last commit from the main line is end Oct. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From alanb at openjdk.java.net Sun Nov 21 19:26:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 21 Nov 2021 19:26:07 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: References: <6FNVAZuVseu_fq0n2k9HBp55F3CZy9RKNd4-nGK2Ytg=.151c2d83-e072-4414-aa05-308e63b3b530@github.com> <5X8_BszkVYY_b9mpfgBE5jCFm7M4rH24dlOUpNi19Gs=.2b33fadf-8b63-4208-ba97-c3281c4a65ca@github.com> Message-ID: On Sun, 21 Nov 2021 19:16:37 GMT, Alan Bateman wrote: >>>BTW: Would it possible to sync up your loom, it looks like hasn't been updated for some time. >> >> Uhm... syncing *what*? > >> Uhm... syncing _what_? > > There was a typo, sorry. I meant your repo as the last commit from the main line is end Oct. > What I actually meant is: This is not apparent to the average Javadoc reader, so I propose to change PipeImpl to not run into this situation instead of asking all calling code to care for that. A Pipe is two channels, one for each end. A typical usage will be for one thread to write to the sink, and another to read from the source. In the test you are only using one end, ignoring the other, so probably unusual. So while it would be possible to retrofit Pipe to implement AutoCloseable, it probably wouldn't fit many usages. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From mcimadamore at openjdk.java.net Mon Nov 22 12:02:47 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 22 Nov 2021 12:02:47 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v25] 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 issues found in CSR review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/79d3d685..1817975f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=24 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=23-24 Stats: 10 lines in 4 files changed: 2 ins; 6 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 mcimadamore at openjdk.java.net Mon Nov 22 12:09:30 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 22 Nov 2021 12:09:30 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v26] 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 pull request now contains 35 commits: - Merge branch 'master' into JEP-419 - Fix javadoc issues found in CSR review - Adopt blessed modofier order - Merge branch 'master' into JEP-419 - Revert removal of upcall MH customization (This change caused spurious VM crashes, so reverting to baseline) - Further tweak upcall safety considerations - Clarify safety considerations for upcalls - Rename MemorySegment::ofAddressNative to MemorySegment::ofAddress (which is consistent with other restricted factories in VaList and NativeSymbol) - Streamline javadoc for package-info - * Add two new CLinker static methods to compute upcall/downcall method types * Clarify section on CLinker downcall type * Add section on CLinker safety guarantees - ... and 25 more: https://git.openjdk.java.net/jdk/compare/d427c79d...29cc6c60 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5907/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=25 Stats: 14700 lines in 193 files changed: 6958 ins; 5126 del; 2616 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 darcy at openjdk.java.net Mon Nov 22 21:55:21 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 22 Nov 2021 21:55:21 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v26] In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 12:09:30 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 with a new target base due to a merge or a rebase. The pull request now contains 35 commits: > > - Merge branch 'master' into JEP-419 > - Fix javadoc issues found in CSR review > - Adopt blessed modofier order > - Merge branch 'master' into JEP-419 > - Revert removal of upcall MH customization > (This change caused spurious VM crashes, so reverting to baseline) > - Further tweak upcall safety considerations > - Clarify safety considerations for upcalls > - Rename MemorySegment::ofAddressNative to MemorySegment::ofAddress > (which is consistent with other restricted factories in VaList and NativeSymbol) > - Streamline javadoc for package-info > - * Add two new CLinker static methods to compute upcall/downcall method types > * Clarify section on CLinker downcall type > * Add section on CLinker safety guarantees > - ... and 25 more: https://git.openjdk.java.net/jdk/compare/d427c79d...29cc6c60 Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From bpb at openjdk.java.net Tue Nov 23 02:22:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 23 Nov 2021 02:22:40 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v5] In-Reply-To: References: Message-ID: > Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8276661: Change getPathWithPrefixForWin32Calls to getPathWithPadForWin32Calls ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6435/files - new: https://git.openjdk.java.net/jdk/pull/6435/files/aecffaf9..5703b012 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6435&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6435&range=03-04 Stats: 17 lines in 2 files changed: 5 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/6435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6435/head:pull/6435 PR: https://git.openjdk.java.net/jdk/pull/6435 From bpb at openjdk.java.net Tue Nov 23 02:22:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 23 Nov 2021 02:22:43 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v4] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 17:32:34 GMT, Brian Burkhalter wrote: >> Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8276661: addPrefixIfNeeded calls addPrefix; remove UNC test Without commit 04, `java/nio/file/Files/CheckPermissions.java` was failing. ------------- PR: https://git.openjdk.java.net/jdk/pull/6435 From bpb at openjdk.java.net Tue Nov 23 17:13:13 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 23 Nov 2021 17:13:13 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v5] In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 02:22:40 GMT, Brian Burkhalter wrote: >> Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8276661: Change getPathWithPrefixForWin32Calls to getPathWithPadForWin32Calls All tiers in the CI pass on Windows. ------------- PR: https://git.openjdk.java.net/jdk/pull/6435 From duke at openjdk.java.net Tue Nov 23 17:41:15 2021 From: duke at openjdk.java.net (Markus KARG) Date: Tue, 23 Nov 2021 17:41:15 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: References: <6FNVAZuVseu_fq0n2k9HBp55F3CZy9RKNd4-nGK2Ytg=.151c2d83-e072-4414-aa05-308e63b3b530@github.com> <5X8_BszkVYY_b9mpfgBE5jCFm7M4rH24dlOUpNi19Gs=.2b33fadf-8b63-4208-ba97-c3281c4a65ca@github.com> Message-ID: On Sun, 21 Nov 2021 19:23:01 GMT, Alan Bateman wrote: >>> Uhm... syncing _what_? >> >> There was a typo, sorry. I meant your repo as the last commit from the main line is end Oct. > >> What I actually meant is: This is not apparent to the average Javadoc reader, so I propose to change PipeImpl to not run into this situation instead of asking all calling code to care for that. > > A Pipe is two channels, one for each end. A typical usage will be for one thread to write to the sink, and another to read from the source. In the test you are only using one end, ignoring the other, so probably unusual. So while it would be possible to retrofit Pipe to implement AutoCloseable, it probably wouldn't fit many usages. Agreed. But back to original topic: Is the PR now in an acceptable shape? ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From lancea at openjdk.java.net Tue Nov 23 18:45:11 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 23 Nov 2021 18:45:11 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v16] In-Reply-To: References: Message-ID: On Sun, 21 Nov 2021 17:51:22 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). >> >> **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). > > Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Closing non-claimed resourced > > Signed-off-by: Markus Karg > - Closing all claimed resources > > Signed-off-by: Markus Karg > - Tests IllegalBlockingModeException > > Signed-off-by: Markus Karg > - JavaDoc proposal by Alan Bateman > - 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo() > > This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferTo(WritableByteChannel), including special treatment of SelectableByteChannel. > > Signed-off-by: Markus Karg The current version of this test is missing the previous updates that were pushed to address the 2GB files being left after the test run. Please update your PR so that reviews are based off of what is in the workspace. test/jdk/java/nio/channels/Channels/TransferTo.java line 194: > 192: try { > 193: // testing arbitrary input (here: empty file) to non-blocking selectable output > 194: try (FileChannel fc = FileChannel.open(Files.createTempFile(null, null)); As mentioned in a previous PR review, please create the temp file in the test directory and provide a prefix. ------------- Changes requested by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5179 From alanb at openjdk.java.net Tue Nov 23 19:11:04 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 23 Nov 2021 19:11:04 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: References: <6FNVAZuVseu_fq0n2k9HBp55F3CZy9RKNd4-nGK2Ytg=.151c2d83-e072-4414-aa05-308e63b3b530@github.com> <5X8_BszkVYY_b9mpfgBE5jCFm7M4rH24dlOUpNi19Gs=.2b33fadf-8b63-4208-ba97-c3281c4a65ca@github.com> Message-ID: On Tue, 23 Nov 2021 17:38:20 GMT, Markus KARG wrote: > Agreed. But back to original topic: Is the PR now in an acceptable shape? I don't have any other comments but I think Lance does make a good point about the temp files. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From mcimadamore at openjdk.java.net Wed Nov 24 11:55:11 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 24 Nov 2021 11:55:11 GMT Subject: Integrated: 8275063: Implementation of Foreign Function & Memory 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 This pull request has now been integrated. Changeset: 96e36071 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/96e36071b63b624d56739b014b457ffc48147c4f Stats: 14700 lines in 193 files changed: 6958 ins; 5126 del; 2616 mod 8275063: Implementation of Foreign Function & Memory API (Second incubator) Reviewed-by: erikj, psandoz, jvernee, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From duke at openjdk.java.net Fri Nov 26 17:52:09 2021 From: duke at openjdk.java.net (Markus KARG) Date: Fri, 26 Nov 2021 17:52:09 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v16] In-Reply-To: References: Message-ID: <-QtBa53iZwRSh6XLkTVOufgC_zoupId_6gbrlTlA8YE=.48fd6bc2-ed91-496b-a32f-fe6d8188f526@github.com> On Tue, 23 Nov 2021 18:39:31 GMT, Lance Andersen wrote: >> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Closing non-claimed resourced >> >> Signed-off-by: Markus Karg >> - Closing all claimed resources >> >> Signed-off-by: Markus Karg >> - Tests IllegalBlockingModeException >> >> Signed-off-by: Markus Karg >> - JavaDoc proposal by Alan Bateman >> - 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo() >> >> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferTo(WritableByteChannel), including special treatment of SelectableByteChannel. >> >> Signed-off-by: Markus Karg > > test/jdk/java/nio/channels/Channels/TransferTo.java line 194: > >> 192: try { >> 193: // testing arbitrary input (here: empty file) to non-blocking selectable output >> 194: try (FileChannel fc = FileChannel.open(Files.createTempFile(null, null)); > > As mentioned in a previous PR review, please create the temp file in the test directory and provide a prefix. With "the test directory", you mean the current working directory `"."`? ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sat Nov 27 09:02:04 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 27 Nov 2021 09:02:04 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 07:39:09 GMT, Alan Bateman wrote: > > @AlanBateman @LanceAndersen You are confusing me. Lance requests style changes, while Alan does not want the changes. These answers are incompatible. _Either_ I change the code according Lance's wishes, _or_ we simple drop this PR. Please find a concensus. > > I think it's better to pause a moment and understand the environment when jtreg runs tests. The important thing is that the current directory (as in user.dir) will be a scratch directory that jtreg has created. My comments are just pointing out that the bookkeeping proposed in this PR to delete files is not needed that you can just change the test to create the temp file in the current directory. We can leave the try-finally that Lance added in the >2GB tests because they are too big to keep for any post failure analysis. Understood, so I will create the temp files in `"."` then and provide a reasonable prefix, keep the try-finally from Lance, and do not manually delete other temp files. ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From duke at openjdk.java.net Sat Nov 27 09:09:18 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 27 Nov 2021 09:09:18 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp [v2] In-Reply-To: References: Message-ID: > This PR proposes to cleanup *all* temp files of the `TransferTo` test, not just the 2GB files. Also it separates the actual test logic from the cleanup logic, so the test cases are simple to understand again as they are not interwoven with cleanup code anymore. Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Revert "Cleaning up temp files" This reverts commit 1fead836777782791943d08b5feae06fa49035dd. - Cleaning up temp files Signed-off-by: Markus Karg ------------- Changes: https://git.openjdk.java.net/jdk/pull/6379/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6379&range=01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6379.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6379/head:pull/6379 PR: https://git.openjdk.java.net/jdk/pull/6379 From duke at openjdk.java.net Sat Nov 27 10:07:36 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 27 Nov 2021 10:07:36 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp [v3] In-Reply-To: References: Message-ID: > This PR proposes to cleanup *all* temp files of the `TransferTo` test, not just the 2GB files. Also it separates the actual test logic from the cleanup logic, so the test cases are simple to understand again as they are not interwoven with cleanup code anymore. Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Creating temp files in current working directory Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6379/files - new: https://git.openjdk.java.net/jdk/pull/6379/files/7b9ac28a..b3719b75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6379&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6379&range=01-02 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6379.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6379/head:pull/6379 PR: https://git.openjdk.java.net/jdk/pull/6379 From duke at openjdk.java.net Sat Nov 27 10:07:37 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 27 Nov 2021 10:07:37 GMT Subject: RFR: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp In-Reply-To: References: Message-ID: <5AiKWNjBA9BTqciwR0nfM8W2AAtSu71l1JKvlxDQqK4=.f9e9d5e5-188d-461f-b3fe-ce8dd7e4fea5@github.com> On Mon, 15 Nov 2021 07:39:09 GMT, Alan Bateman wrote: >> I don't think we need this. Instead, it would be better if the tests uses the test work directory so the files are easily found for post failure analysis. This isn't practical for the tests that create >2GB files so I think leave the code that Lance put in there to delete them so they aren't archived when the work directory is zipped up. > >> @AlanBateman @LanceAndersen You are confusing me. Lance requests style changes, while Alan does not want the changes. These answers are incompatible. _Either_ I change the code according Lance's wishes, _or_ we simple drop this PR. Please find a concensus. > > I think it's better to pause a moment and understand the environment when jtreg runs tests. The important thing is that the current directory (as in user.dir) will be a scratch directory that jtreg has created. My comments are just pointing out that the bookkeeping proposed in this PR to delete files is not needed that you can just change the test to create the temp file in the current directory. We can leave the try-finally that Lance added in the >2GB tests because they are too big to keep for any post failure analysis. @AlanBateman IIUC then since https://github.com/openjdk/jdk/pull/6379/commits/b3719b75b68f32cad3b017d3ff8a0e8520ffa78c this PR is now in the fashion that you proposed. Please correct me if I'm wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/6379 From duke at openjdk.java.net Sat Nov 27 16:32:37 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 27 Nov 2021 16:32:37 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v17] In-Reply-To: References: Message-ID: > 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). > > **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Closing non-claimed resourced Signed-off-by: Markus Karg - Closing all claimed resources Signed-off-by: Markus Karg - Tests IllegalBlockingModeException Signed-off-by: Markus Karg - JavaDoc proposal by Alan Bateman - 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo() This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferTo(WritableByteChannel), including special treatment of SelectableByteChannel. Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5179/files - new: https://git.openjdk.java.net/jdk/pull/5179/files/c4904cac..5a2b441f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=15-16 Stats: 23816 lines in 438 files changed: 14338 ins; 6199 del; 3279 mod Patch: https://git.openjdk.java.net/jdk/pull/5179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5179/head:pull/5179 PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sat Nov 27 16:57:36 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 27 Nov 2021 16:57:36 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v18] In-Reply-To: References: Message-ID: > 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). > > **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Creating temp file in current working directory Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5179/files - new: https://git.openjdk.java.net/jdk/pull/5179/files/5a2b441f..807139e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=16-17 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5179/head:pull/5179 PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sat Nov 27 16:57:38 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 27 Nov 2021 16:57:38 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v16] In-Reply-To: <-QtBa53iZwRSh6XLkTVOufgC_zoupId_6gbrlTlA8YE=.48fd6bc2-ed91-496b-a32f-fe6d8188f526@github.com> References: <-QtBa53iZwRSh6XLkTVOufgC_zoupId_6gbrlTlA8YE=.48fd6bc2-ed91-496b-a32f-fe6d8188f526@github.com> Message-ID: On Fri, 26 Nov 2021 17:49:07 GMT, Markus KARG wrote: >> test/jdk/java/nio/channels/Channels/TransferTo.java line 194: >> >>> 192: try { >>> 193: // testing arbitrary input (here: empty file) to non-blocking selectable output >>> 194: try (FileChannel fc = FileChannel.open(Files.createTempFile(null, null)); >> >> As mentioned in a previous PR review, please create the temp file in the test directory and provide a prefix. > > With "the test directory", you mean the current working directory `"."`? Done in https://github.com/openjdk/jdk/pull/5179/commits/807139e0daf0647a868b8eab45bfb5efac944410. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sat Nov 27 17:00:09 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 27 Nov 2021 17:00:09 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v14] In-Reply-To: References: <6FNVAZuVseu_fq0n2k9HBp55F3CZy9RKNd4-nGK2Ytg=.151c2d83-e072-4414-aa05-308e63b3b530@github.com> <5X8_BszkVYY_b9mpfgBE5jCFm7M4rH24dlOUpNi19Gs=.2b33fadf-8b63-4208-ba97-c3281c4a65ca@github.com> Message-ID: On Tue, 23 Nov 2021 19:07:55 GMT, Alan Bateman wrote: >> Agreed. But back to original topic: Is the PR now in an acceptable shape? > >> Agreed. But back to original topic: Is the PR now in an acceptable shape? > > I don't have any other comments but I think Lance does make a good point about the temp files. Done. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sat Nov 27 17:00:08 2021 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 27 Nov 2021 17:00:08 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v16] In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 18:41:41 GMT, Lance Andersen wrote: > The current version of this test is missing the previous updates that were pushed to address the 2GB files being left after the test run. Please update your PR so that reviews are based off of what is in the workspace. I just rebased this PR on master so now it does contain Lance`s 2GB-temp-file-removal. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From duke at openjdk.java.net Sat Nov 27 17:45:02 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Sat, 27 Nov 2021 17:45:02 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 let's wait for review a bit more ------------- PR: https://git.openjdk.java.net/jdk/pull/5481 From alanb at openjdk.java.net Sun Nov 28 20:04:02 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 28 Nov 2021 20:04:02 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v18] In-Reply-To: References: Message-ID: On Sat, 27 Nov 2021 16:57:36 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). >> >> **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Creating temp file in current working directory > > Signed-off-by: Markus Karg Thanks for the update and re-basing. I don't have any more comments, let's give Lance a day or two to see if he has any more comments on the temporary file location/naming that he suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From alanb at openjdk.java.net Mon Nov 29 14:43:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 29 Nov 2021 14:43:08 GMT Subject: RFR: 8276661: (fs) UserDefinedFileAttributeView no longer works with long path (win) [v5] In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 02:22:40 GMT, Brian Burkhalter wrote: >> Please consider this change which uses a new method `WindowsPath::getPathWithPrefixForWin32Calls`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8276661: Change getPathWithPrefixForWin32Calls to getPathWithPadForWin32Calls The latest iteration is 5703b012 which adds a pad count to the API exposed by WindowsPath. I think we need to bury that. The previous iteration with getPathForWin32Calls and getPathWithPrefixForWin32Calls was much cleaner. For the discussion it would be useful to know if test failure was due to MAX_LONG_PATH and whether the limit includes the colon and the stream name. ------------- PR: https://git.openjdk.java.net/jdk/pull/6435 From bpb at openjdk.java.net Mon Nov 29 17:02:25 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 29 Nov 2021 17:02:25 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: <3CWB_ZuCk86dFu06M-xfUy0JoAQ1QWnwRLDutNf3mg0=.d1c32750-b9ca-4c9a-9258-2a124dc9c629@github.com> 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 lancea at openjdk.java.net Mon Nov 29 19:55:18 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 29 Nov 2021 19:55:18 GMT Subject: RFR: 8276779: (ch) InputStream returned by Channels.newInputStream should have fast path for SelectableChannels [v18] In-Reply-To: References: Message-ID: On Sat, 27 Nov 2021 16:57:36 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). >> >> **Update:** This sub-issue *only* defines the work to be done to implement JDK-8265891 *solely* for the particular case of FileChannel.transferTo(WriteableByteChannel), including special treatment of SelectableByteChannel, as the `master` branch already contains code to handle the specific case of FileChannel.transferTo(FileChannel). > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Creating temp file in current working directory > > Signed-off-by: Markus Karg We are getting closer, the methods fileChannelInput/Output should also create the temp files in the working directory and include a prefix for name construction. ------------- PR: https://git.openjdk.java.net/jdk/pull/5179 From bpb at openjdk.java.net Tue Nov 30 01:31:11 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 30 Nov 2021 01:31: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: 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 continue ... ------------- PR: https://git.openjdk.java.net/jdk/pull/5623