From duke at openjdk.org Mon Oct 2 12:47:14 2023 From: duke at openjdk.org (David Voit) Date: Mon, 2 Oct 2023 12:47:14 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v3] In-Reply-To: References: Message-ID: On Fri, 29 Sep 2023 16:35:09 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision: > > - Wrap copy_statx_attributes with ifdef __linux__ > - Fix compile warnings. > - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 212: > 210: > 211: #if defined(_DARWIN_FEATURE_64_BIT_INODE) || defined(__linux__) > 212: static jfieldID attrs_st_birthtime_sec; birthtime_nsec missing? Just set it to zero on darwin and use the value under linux? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1341667257 From sgehwolf at openjdk.org Mon Oct 2 12:47:17 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 2 Oct 2023 12:47:17 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v3] In-Reply-To: References: Message-ID: On Fri, 29 Sep 2023 17:27:03 GMT, Brian Burkhalter wrote: >> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision: >> >> - Wrap copy_statx_attributes with ifdef __linux__ >> - Fix compile warnings. >> - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 34: > >> 32: */ >> 33: >> 34: import java.lang.reflect.Method; > > Instead of using reflective access, would it be possible to use the "os.version" property and a minimum kernel version (4.11?)? > > > jshell> System.getProperty("os.version") > $1 ==> "5.19.0-50-generic" > > jshell> > bpb at bpb-vb-u2204:~$ uname -a > Linux bpb-vb-u2204 5.19.0-50-generic #50-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 10 18:24:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux``` It's not the full story. On an alpine build, on `5.19.0-50` it would report the wrong value. It's not supported, since the libc impl doesn't support it. The kernel itself would as a regular, non-alpine build, attests. I could use `!Platform.isMusl()` in addition if that sounds OK? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1342638406 From sgehwolf at openjdk.org Mon Oct 2 13:11:17 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 2 Oct 2023 13:11:17 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v3] In-Reply-To: References: Message-ID: On Fri, 29 Sep 2023 18:07:49 GMT, David Voit wrote: >> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision: >> >> - Wrap copy_statx_attributes with ifdef __linux__ >> - Fix compile warnings. >> - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux > > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 212: > >> 210: >> 211: #if defined(_DARWIN_FEATURE_64_BIT_INODE) || defined(__linux__) >> 212: static jfieldID attrs_st_birthtime_sec; > > birthtime_nsec missing? Just set it to zero on darwin and use the value under linux? I've deliberately omitted that change here, not sure if this change of behaviour is wanted as it would add a field in `UnixFileAttributes` (it was part of the v2 patch). @bplb @AlanBateman Thoughts? I can include it of course, but don't want to go in circles. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1342671545 From sgehwolf at openjdk.org Mon Oct 2 13:15:18 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 2 Oct 2023 13:15:18 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v3] In-Reply-To: References: Message-ID: <5W2DUmdAB-ww-w76g6G9LCL9aWAeu8ENartgA1_WfG0=.b2fbf964-eaf4-4405-b51a-50693462a764@github.com> On Fri, 29 Sep 2023 17:27:03 GMT, Brian Burkhalter wrote: >> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision: >> >> - Wrap copy_statx_attributes with ifdef __linux__ >> - Fix compile warnings. >> - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 34: > >> 32: */ >> 33: >> 34: import java.lang.reflect.Method; > > Instead of using reflective access, would it be possible to use the "os.version" property and a minimum kernel version (4.11?)? > > > jshell> System.getProperty("os.version") > $1 ==> "5.19.0-50-generic" > > jshell> > bpb at bpb-vb-u2204:~$ uname -a > Linux bpb-vb-u2204 5.19.0-50-generic #50-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 10 18:24:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux``` Hmm, @bplb `Platform.isMusl()` doesn't seem to work reliably. Running an alpine binary on Linux (Fedora) in my case, breaks this test as it gets `Platform.isMusl() == false`. Also, there is a chance where the JDK runs on an old glibc (<2.28) and new enough kernel, where this wouldn't work either. Using the reflective approach seems most consistent with what the code is actually doing. More thoughts? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1342677367 From sgehwolf at openjdk.org Mon Oct 2 13:21:18 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 2 Oct 2023 13:21:18 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v4] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Fix style ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/070c413a..7aa251b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From jvernee at openjdk.org Mon Oct 2 16:07:09 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 2 Oct 2023 16:07:09 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v33] In-Reply-To: References: Message-ID: <0r5bNt-ez79b7DrOJUuHCPguBQkn3MtEJdoQFqVuWxA=.86265508-9e7d-4fab-a851-35c5c138255d@github.com> > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Remove PIP annotation from jdk.incubator.vector ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/17dacbbd..cc89a519 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=31-32 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103 PR: https://git.openjdk.org/jdk/pull/15103 From duke at openjdk.org Mon Oct 2 18:06:36 2023 From: duke at openjdk.org (David Voit) Date: Mon, 2 Oct 2023 18:06:36 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v3] In-Reply-To: References: Message-ID: On Mon, 2 Oct 2023 13:07:56 GMT, Severin Gehwolf wrote: >> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 212: >> >>> 210: >>> 211: #if defined(_DARWIN_FEATURE_64_BIT_INODE) || defined(__linux__) >>> 212: static jfieldID attrs_st_birthtime_sec; >> >> birthtime_nsec missing? Just set it to zero on darwin and use the value under linux? > > I've deliberately omitted that change here, not sure if this change of behaviour is wanted as it would add a field in `UnixFileAttributes` (it was part of the v2 patch). @bplb @AlanBateman Thoughts? I can include it of course, but don't want to go in circles. Understood, seems just a little bit silly that a limitation in a different kernel (darwin) artificially limits the birthtime here, while it easily accessible with statx. Otherwise this patch series looks quite good! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1342996360 From bpb at openjdk.org Mon Oct 2 18:51:02 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 2 Oct 2023 18:51:02 GMT Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with AccessDeniedException [v2] In-Reply-To: References: Message-ID: > The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8317128: Remove replaceExistingOrEmpty method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15991/files - new: https://git.openjdk.org/jdk/pull/15991/files/365149c7..4a34ff3b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15991&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15991&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15991/head:pull/15991 PR: https://git.openjdk.org/jdk/pull/15991 From bpb at openjdk.org Mon Oct 2 18:51:05 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 2 Oct 2023 18:51:05 GMT Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with AccessDeniedException [v2] In-Reply-To: <5ar7nVuS0bVkQh4kZVvY7Tx1AcBCiAuawllebwsyZYY=.2848d320-d2dc-4433-863b-bcfd9120ea21@github.com> References: <5ar7nVuS0bVkQh4kZVvY7Tx1AcBCiAuawllebwsyZYY=.2848d320-d2dc-4433-863b-bcfd9120ea21@github.com> Message-ID: On Sat, 30 Sep 2023 06:24:25 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8317128: Remove replaceExistingOrEmpty method > > src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 150: > >> 148: Files.createDirectory(target); >> 149: } else { >> 150: try (InputStream in = Files.newInputStream(source)) { > > If we are you reverting that then I assume you also should revert the change to L147 too, meaning replaceExistingOrEmpty() isn't needed now. `replaceExistingOrEmpty()` removed in 4a34ff3b36bbcbd43139f7888ac4d953ecef91da. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15991#discussion_r1343030243 From alanb at openjdk.org Mon Oct 2 19:46:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 2 Oct 2023 19:46:22 GMT Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with AccessDeniedException [v2] In-Reply-To: References: Message-ID: <7Sj_4_El-A_SdU8g7r8GzavYrT0MfiRZDJ2GRKXU5MU=.136fa309-2e3c-4dfa-9a78-347eedac3c4f@github.com> On Mon, 2 Oct 2023 18:51:02 GMT, Brian Burkhalter wrote: >> The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8317128: Remove replaceExistingOrEmpty method Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15991#pullrequestreview-1653381715 From sgehwolf at openjdk.org Tue Oct 3 10:02:32 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 10:02:32 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v5] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Add support for nano seconds for btime on Linux ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/7aa251b6..643251db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=03-04 Stats: 19 lines in 2 files changed: 15 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From sgehwolf at openjdk.org Tue Oct 3 10:05:25 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 10:05:25 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v3] In-Reply-To: References: Message-ID: On Mon, 2 Oct 2023 18:03:33 GMT, David Voit wrote: >> I've deliberately omitted that change here, not sure if this change of behaviour is wanted as it would add a field in `UnixFileAttributes` (it was part of the v2 patch). @bplb @AlanBateman Thoughts? I can include it of course, but don't want to go in circles. > > Understood, seems just a little bit silly that a limitation in a different kernel (darwin) artificially limits the birthtime here, while it easily accessible with statx. Otherwise this patch series looks quite good! Well, I've reconsidered. It's fairly trivial to support, so I've added it. The latest patch does this. It's an incremental webrev change so we can go back if not desired. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343843993 From sgehwolf at openjdk.org Tue Oct 3 10:05:27 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 10:05:27 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v3] In-Reply-To: <5W2DUmdAB-ww-w76g6G9LCL9aWAeu8ENartgA1_WfG0=.b2fbf964-eaf4-4405-b51a-50693462a764@github.com> References: <5W2DUmdAB-ww-w76g6G9LCL9aWAeu8ENartgA1_WfG0=.b2fbf964-eaf4-4405-b51a-50693462a764@github.com> Message-ID: On Mon, 2 Oct 2023 13:12:20 GMT, Severin Gehwolf wrote: >> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 34: >> >>> 32: */ >>> 33: >>> 34: import java.lang.reflect.Method; >> >> Instead of using reflective access, would it be possible to use the "os.version" property and a minimum kernel version (4.11?)? >> >> >> jshell> System.getProperty("os.version") >> $1 ==> "5.19.0-50-generic" >> >> jshell> >> bpb at bpb-vb-u2204:~$ uname -a >> Linux bpb-vb-u2204 5.19.0-50-generic #50-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 10 18:24:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux``` > > Hmm, @bplb `Platform.isMusl()` doesn't seem to work reliably. Running an alpine binary on Linux (Fedora) in my case, breaks this test as it gets `Platform.isMusl() == false`. Also, there is a chance where the JDK runs on an old glibc (<2.28) and new enough kernel, where this wouldn't work either. Using the reflective approach seems most consistent with what the code is actually doing. More thoughts? For now I'd like to keep the reflective approach until we know a better way to determine support correctly otherwise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343845097 From alanb at openjdk.org Tue Oct 3 10:14:19 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Oct 2023 10:14:19 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v5] In-Reply-To: References: Message-ID: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com> On Tue, 3 Oct 2023 10:02:32 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Add support for nano seconds for btime on Linux src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 28: > 26: package sun.nio.fs; > 27: > 28: import java.nio.file.attribute.BasicFileAttributes; I assume you'll update the copyright date on this file. src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 706: > 704: #if defined(__linux__) > 705: } > 706: #endif Can you replace this with #if defined(__linux) .. #else .. #endif as it will make it easier to read. There are several places where we'll need to fix the indent with nested ifdef usage as it's hard to ready right now. test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 140: > 138: return (boolean)supportsBirthTime.invoke(null); > 139: } catch (Throwable e) { > 140: throw new RuntimeException("Illegal state!"); I agree with Brian, we need to find a better way to do this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343854783 PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343857110 PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343857459 From alanb at openjdk.org Tue Oct 3 10:18:37 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Oct 2023 10:18:37 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v5] In-Reply-To: References: Message-ID: On Tue, 3 Oct 2023 10:02:32 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Add support for nano seconds for btime on Linux src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 350: > 348: #if defined (__linux__) // Linux has nsec granularity > 349: attrs_st_birthtime_nsec = (*env)->GetFieldID(env, clazz, "st_birthtime_nsec", "J"); > 350: CHECK_NULL_RETURN(attrs_st_birthtime_sec, 0); This should check attrs_st_birthtime_nsec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343863736 From sgehwolf at openjdk.org Tue Oct 3 11:39:37 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 11:39:37 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v5] In-Reply-To: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com> References: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com> Message-ID: On Tue, 3 Oct 2023 10:09:30 GMT, Alan Bateman wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Add support for nano seconds for btime on Linux > > src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 28: > >> 26: package sun.nio.fs; >> 27: >> 28: import java.nio.file.attribute.BasicFileAttributes; > > I assume you'll update the copyright date on this file. OK. > test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 140: > >> 138: return (boolean)supportsBirthTime.invoke(null); >> 139: } catch (Throwable e) { >> 140: throw new RuntimeException("Illegal state!"); > > I agree with Brian, we need to find a better way to do this. Sure, happy to. Any suggestions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343956701 PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343955999 From sgehwolf at openjdk.org Tue Oct 3 11:47:43 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 11:47:43 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v5] In-Reply-To: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com> References: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com> Message-ID: On Tue, 3 Oct 2023 10:11:28 GMT, Alan Bateman wrote: > Can you replace this with #if defined(__linux) .. #else .. #endif as it will make it easier to read. I'm not sure I follow. We need the `statx` code *and* the old `stat64` code on Linux as that's the fall-back code when `statx` isn't supported. We don't need the `statx` code on other platforms. If I used `#if defined(__linux__) ... #else ... #endif` instead, I wouldn't get the stat64 code on Linux without duplication. What am I missing? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343966374 From sgehwolf at openjdk.org Tue Oct 3 11:59:13 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 11:59:13 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v6] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with three additional commits since the last revision: - Fix indents - Check correct fieldID - Add copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/643251db..5149545d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=04-05 Stats: 32 lines in 2 files changed: 0 ins; 1 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From sgehwolf at openjdk.org Tue Oct 3 11:59:13 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 11:59:13 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v5] In-Reply-To: References: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com> Message-ID: On Tue, 3 Oct 2023 11:43:51 GMT, Severin Gehwolf wrote: >> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 706: >> >>> 704: #if defined(__linux__) >>> 705: } >>> 706: #endif >> >> Can you replace this with #if defined(__linux) .. #else .. #endif as it will make it easier to read. There are several places where we'll need to fix the indent with nested ifdef usage as it's hard to ready right now. > >> Can you replace this with #if defined(__linux) .. #else .. #endif as it will make it easier to read. > > I'm not sure I follow. We need the `statx` code *and* the old `stat64` code on Linux as that's the fall-back code when `statx` isn't supported. We don't need the `statx` code on other platforms. If I used `#if defined(__linux__) ... #else ... #endif` instead, I wouldn't get the stat64 code on Linux without duplication. What am I missing? I've added indents. Not sure if it's any better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343978722 From alanb at openjdk.org Tue Oct 3 12:05:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Oct 2023 12:05:36 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v5] In-Reply-To: References: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com> Message-ID: On Tue, 3 Oct 2023 11:54:06 GMT, Severin Gehwolf wrote: >>> Can you replace this with #if defined(__linux) .. #else .. #endif as it will make it easier to read. >> >> I'm not sure I follow. We need the `statx` code *and* the old `stat64` code on Linux as that's the fall-back code when `statx` isn't supported. We don't need the `statx` code on other platforms. If I used `#if defined(__linux__) ... #else ... #endif` instead, I wouldn't get the stat64 code on Linux without duplication. What am I missing? > > I've added indents. Not sure if it's any better. > What am I missing? If you remove the "} else {" then it will be a lot simpler. The thing that I don't like is the `#if defined(__linux__) } #endif` at the end of each function, we shouldn't need that and the code will be a lot easier to read if the "} else {" is removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1343987930 From sgehwolf at openjdk.org Tue Oct 3 12:37:35 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 12:37:35 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v5] In-Reply-To: References: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com> Message-ID: <3znWaDuChhRyt0U-9_hPo8wSmkfTZlhUvVuJCy1Y4ho=.66c7e041-d6ce-4ecc-9ea0-8645c71a605b@github.com> On Tue, 3 Oct 2023 12:02:07 GMT, Alan Bateman wrote: >> I've added indents. Not sure if it's any better. > >> What am I missing? > > If you remove the "} else {" then it will be a lot simpler. The thing that I don't like is the `#if defined(__linux__) } #endif` at the end of each function, we shouldn't need that and the code will be a lot easier to read if the "} else {" is removed. OK, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344025907 From sgehwolf at openjdk.org Tue Oct 3 12:37:38 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 12:37:38 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v5] In-Reply-To: References: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com> Message-ID: On Tue, 3 Oct 2023 11:35:41 GMT, Severin Gehwolf wrote: >> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 140: >> >>> 138: return (boolean)supportsBirthTime.invoke(null); >>> 139: } catch (Throwable e) { >>> 140: throw new RuntimeException("Illegal state!"); >> >> I agree with Brian, we need to find a better way to do this. > > Sure, happy to. Any suggestions? I'm experimenting with a native function in a test helper. Hopefully that'll be more amenable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344027014 From sgehwolf at openjdk.org Tue Oct 3 13:07:21 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 13:07:21 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v7] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: - Cleanup UnixNativeDispatcher.c - Refactor test so as to not use reflection ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/5149545d..3b30596d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=05-06 Stats: 159 lines in 4 files changed: 99 ins; 58 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From sgehwolf at openjdk.org Tue Oct 3 13:07:23 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 13:07:23 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v5] In-Reply-To: <3znWaDuChhRyt0U-9_hPo8wSmkfTZlhUvVuJCy1Y4ho=.66c7e041-d6ce-4ecc-9ea0-8645c71a605b@github.com> References: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com> <3znWaDuChhRyt0U-9_hPo8wSmkfTZlhUvVuJCy1Y4ho=.66c7e041-d6ce-4ecc-9ea0-8645c71a605b@github.com> Message-ID: On Tue, 3 Oct 2023 12:33:30 GMT, Severin Gehwolf wrote: >>> What am I missing? >> >> If you remove the "} else {" then it will be a lot simpler. The thing that I don't like is the `#if defined(__linux__) } #endif` at the end of each function, we shouldn't need that and the code will be a lot easier to read if the "} else {" is removed. > > OK, thanks. Should be fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344067971 From sgehwolf at openjdk.org Tue Oct 3 13:07:25 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 13:07:25 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v5] In-Reply-To: References: <9XA_3y-8fx8Jp_4xjJBfIvKbM3phVC15imyvhZCw7j4=.c553ed7b-cff8-4b1a-861a-f9a21d030266@github.com> Message-ID: <8fIPHLIWaXOXEzVH-JglIuSmWxd5Zz1Z2Q1lcXSXdBY=.a58645fe-2801-4db3-bc80-a2383639de9c@github.com> On Tue, 3 Oct 2023 12:34:22 GMT, Severin Gehwolf wrote: >> Sure, happy to. Any suggestions? > > I'm experimenting with a native function in a test helper. Hopefully that'll be more amenable. That's what's being used in the latest version now. No more reflection. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344067657 From sgehwolf at openjdk.org Tue Oct 3 17:41:24 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Oct 2023 17:41:24 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v8] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf 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 12 additional commits since the last revision: - Link libCreationTimeHelper with -ldl - Merge branch 'master' into JDK-8316304-statx-create-time-new - Cleanup UnixNativeDispatcher.c - Refactor test so as to not use reflection - Fix indents - Check correct fieldID - Add copyright - Add support for nano seconds for btime on Linux - Fix style - Wrap copy_statx_attributes with ifdef __linux__ - ... and 2 more: https://git.openjdk.org/jdk/compare/590d707b...83347ec1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/3b30596d..83347ec1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=06-07 Stats: 80501 lines in 2327 files changed: 31105 ins; 14997 del; 34399 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From bpb at openjdk.org Tue Oct 3 18:10:56 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 3 Oct 2023 18:10:56 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v8] In-Reply-To: References: Message-ID: On Tue, 3 Oct 2023 17:41:24 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf 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 12 additional commits since the last revision: > > - Link libCreationTimeHelper with -ldl > - Merge branch 'master' into JDK-8316304-statx-create-time-new > - Cleanup UnixNativeDispatcher.c > - Refactor test so as to not use reflection > - Fix indents > - Check correct fieldID > - Add copyright > - Add support for nano seconds for btime on Linux > - Fix style > - Wrap copy_statx_attributes with ifdef __linux__ > - ... and 2 more: https://git.openjdk.org/jdk/compare/65113b79...83347ec1 test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 33: > 31: { > 32: #if defined(__linux__) > 33: void* statx_func = dlsym(RTLD_DEFAULT, "statx"); For commit 04226fd470bc9a238e83606cb7f62ebd64d44421, which is the penultimate commit, I am seeing the build error: open/test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c:33: error: undefined reference to 'dlsym'``` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344525162 From bpb at openjdk.org Wed Oct 4 00:15:01 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 4 Oct 2023 00:15:01 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v8] In-Reply-To: References: Message-ID: On Tue, 3 Oct 2023 18:08:11 GMT, Brian Burkhalter wrote: >> Severin Gehwolf 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 12 additional commits since the last revision: >> >> - Link libCreationTimeHelper with -ldl >> - Merge branch 'master' into JDK-8316304-statx-create-time-new >> - Cleanup UnixNativeDispatcher.c >> - Refactor test so as to not use reflection >> - Fix indents >> - Check correct fieldID >> - Add copyright >> - Add support for nano seconds for btime on Linux >> - Fix style >> - Wrap copy_statx_attributes with ifdef __linux__ >> - ... and 2 more: https://git.openjdk.org/jdk/compare/6e6821d7...83347ec1 > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 33: > >> 31: { >> 32: #if defined(__linux__) >> 33: void* statx_func = dlsym(RTLD_DEFAULT, "statx"); > > For commit 04226fd470bc9a238e83606cb7f62ebd64d44421, which is the penultimate commit, I am seeing the build error: > > > open/test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c:33: error: undefined reference to 'dlsym'``` The above build failure is fixed in commit 83347ec1c9fee2a859470fff8e391c5f6970d226. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1344900913 From sgehwolf at openjdk.org Wed Oct 4 08:16:40 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 4 Oct 2023 08:16:40 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v8] In-Reply-To: References: Message-ID: On Wed, 4 Oct 2023 00:12:26 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 33: >> >>> 31: { >>> 32: #if defined(__linux__) >>> 33: void* statx_func = dlsym(RTLD_DEFAULT, "statx"); >> >> For commit 04226fd470bc9a238e83606cb7f62ebd64d44421, which is the penultimate commit, I am seeing the build error: >> >> >> open/test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c:33: error: undefined reference to 'dlsym'``` > > The above build failure is fixed in commit 83347ec1c9fee2a859470fff8e391c5f6970d226. Yes, sorry about that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1345388943 From sgehwolf at openjdk.org Wed Oct 4 10:06:40 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 4 Oct 2023 10:06:40 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v8] In-Reply-To: References: Message-ID: <2rRIBH3ENt-bNRuJXRof5WXlJpaDR59eGdCw2xut6Y8=.9ab76c02-49f9-48a0-8031-ec4059b528c8@github.com> On Tue, 3 Oct 2023 17:41:24 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf 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 12 additional commits since the last revision: > > - Link libCreationTimeHelper with -ldl > - Merge branch 'master' into JDK-8316304-statx-create-time-new > - Cleanup UnixNativeDispatcher.c > - Refactor test so as to not use reflection > - Fix indents > - Check correct fieldID > - Add copyright > - Add support for nano seconds for btime on Linux > - Fix style > - Wrap copy_statx_attributes with ifdef __linux__ > - ... and 2 more: https://git.openjdk.org/jdk/compare/d9b097ab...83347ec1 x86 (32 bit) GHA failure seems unrelated. My testing seems OK for this patch. Feel free to run your own. Please let me know if there is anything else that still needs to be addressed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1746548920 From stuefe at openjdk.org Wed Oct 4 12:40:43 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 4 Oct 2023 12:40:43 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v8] In-Reply-To: References: Message-ID: <5nDIXc3OLGBrTawxGQnmeHTiajj0LeS_hhCOGLOHR6A=.af6116fe-5eaf-43af-b9fd-2c894f5effc3@github.com> On Tue, 3 Oct 2023 17:41:24 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf 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 12 additional commits since the last revision: > > - Link libCreationTimeHelper with -ldl > - Merge branch 'master' into JDK-8316304-statx-create-time-new > - Cleanup UnixNativeDispatcher.c > - Refactor test so as to not use reflection > - Fix indents > - Check correct fieldID > - Add copyright > - Add support for nano seconds for btime on Linux > - Fix style > - Wrap copy_statx_attributes with ifdef __linux__ > - ... and 2 more: https://git.openjdk.org/jdk/compare/ca543a9a...83347ec1 src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 80: > 78: // support. We still want to ensure we can call statx at runtime > 79: // if the runtime glibc version supports it (>= 2.28) > 80: #ifndef __NR_statx As long as we have to accommodate the case where struct statx is not defined, we may just as well do it always: just define a structure binary compatible to statx but named differently (e.g. my_statx) to prevent name clashes in case the structure happens to be defined already from libc; then use that structure as return type for your function pointer. The advantage would be you don't need to know and depend on __NR_statx, and you don't need to include asm/unistd. And no two cases to build and test. We do this already in other places, see e.g. the dynamic inclusion of mallinfo2() in os_linux.cpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1345719922 From sgehwolf at openjdk.org Wed Oct 4 13:24:44 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 4 Oct 2023 13:24:44 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v8] In-Reply-To: <5nDIXc3OLGBrTawxGQnmeHTiajj0LeS_hhCOGLOHR6A=.af6116fe-5eaf-43af-b9fd-2c894f5effc3@github.com> References: <5nDIXc3OLGBrTawxGQnmeHTiajj0LeS_hhCOGLOHR6A=.af6116fe-5eaf-43af-b9fd-2c894f5effc3@github.com> Message-ID: On Wed, 4 Oct 2023 12:31:24 GMT, Thomas Stuefe wrote: >> Severin Gehwolf 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 12 additional commits since the last revision: >> >> - Link libCreationTimeHelper with -ldl >> - Merge branch 'master' into JDK-8316304-statx-create-time-new >> - Cleanup UnixNativeDispatcher.c >> - Refactor test so as to not use reflection >> - Fix indents >> - Check correct fieldID >> - Add copyright >> - Add support for nano seconds for btime on Linux >> - Fix style >> - Wrap copy_statx_attributes with ifdef __linux__ >> - ... and 2 more: https://git.openjdk.org/jdk/compare/b213660e...83347ec1 > > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 80: > >> 78: // support. We still want to ensure we can call statx at runtime >> 79: // if the runtime glibc version supports it (>= 2.28) >> 80: #ifndef __NR_statx > > As long as we have to accommodate the case where struct statx is not defined, we may just as well do it always: just define a structure binary compatible to statx but named differently (e.g. my_statx) to prevent name clashes in case the structure happens to be defined already from libc; then use that structure as return type for your function pointer. > > The advantage would be you don't need to know and depend on __NR_statx, and you don't need to include asm/unistd. And no two cases to build and test. > > We do this already in other places, see e.g. the dynamic inclusion of mallinfo2() in os_linux.cpp. OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1345789779 From sgehwolf at openjdk.org Wed Oct 4 16:10:38 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 4 Oct 2023 16:10:38 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v9] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Use custom but compatible statx struct always ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/83347ec1..a196c822 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=07-08 Stats: 22 lines in 1 file changed: 1 ins; 6 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From sgehwolf at openjdk.org Wed Oct 4 16:11:23 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 4 Oct 2023 16:11:23 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v8] In-Reply-To: References: <5nDIXc3OLGBrTawxGQnmeHTiajj0LeS_hhCOGLOHR6A=.af6116fe-5eaf-43af-b9fd-2c894f5effc3@github.com> Message-ID: <8fiFrrNfDNq5sUhuYT2puOm7Z3C8H2XPSWkCcOh6xMg=.250d4230-3267-49d7-93c1-3c4191053bf4@github.com> On Wed, 4 Oct 2023 13:21:51 GMT, Severin Gehwolf wrote: >> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 80: >> >>> 78: // support. We still want to ensure we can call statx at runtime >>> 79: // if the runtime glibc version supports it (>= 2.28) >>> 80: #ifndef __NR_statx >> >> As long as we have to accommodate the case where struct statx is not defined, we may just as well do it always: just define a structure binary compatible to statx but named differently (e.g. my_statx) to prevent name clashes in case the structure happens to be defined already from libc; then use that structure as return type for your function pointer. >> >> The advantage would be you don't need to know and depend on __NR_statx, and you don't need to include asm/unistd. And no two cases to build and test. >> >> We do this already in other places, see e.g. the dynamic inclusion of mallinfo2() in os_linux.cpp. > > OK. Should be done now in the latest patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1345930010 From stuefe at openjdk.org Wed Oct 4 17:18:47 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 4 Oct 2023 17:18:47 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v9] In-Reply-To: References: Message-ID: On Wed, 4 Oct 2023 16:10:38 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Use custom but compatible statx struct always src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 722: > 720: } > 721: } > 722: #endif Are you missing a return here or did you really intent to call both `statx` and `lstat64` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1346212918 From sgehwolf at openjdk.org Wed Oct 4 19:00:54 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 4 Oct 2023 19:00:54 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v9] In-Reply-To: References: Message-ID: On Wed, 4 Oct 2023 17:15:20 GMT, Thomas Stuefe wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Use custom but compatible statx struct always > > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 722: > >> 720: } >> 721: } >> 722: #endif > > Are you missing a return here or did you really intent to call both `statx` and `lstat64` ? Good catch! The original code had this in `if () ... else ...` blocks. Will fix. It needs to get fixed elsewhere too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1346326389 From sgehwolf at openjdk.org Wed Oct 4 19:15:01 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 4 Oct 2023 19:15:01 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v10] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Add missing returns when statx is available ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/a196c822..ad428030 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=08-09 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From bpb at openjdk.org Wed Oct 4 23:38:43 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 4 Oct 2023 23:38:43 GMT Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with AccessDeniedException [v3] In-Reply-To: References: Message-ID: > The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8317128: Add different provider read access check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15991/files - new: https://git.openjdk.org/jdk/pull/15991/files/4a34ff3b..299ffa51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15991&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15991&range=01-02 Stats: 10 lines in 1 file changed: 9 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15991/head:pull/15991 PR: https://git.openjdk.org/jdk/pull/15991 From stuefe at openjdk.org Thu Oct 5 06:00:19 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 5 Oct 2023 06:00:19 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v10] In-Reply-To: References: Message-ID: On Wed, 4 Oct 2023 19:15:01 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Add missing returns when statx is available Looks good to me now, but Brian or Alan should okay this too. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1658926831 From sgehwolf at openjdk.org Thu Oct 5 08:13:22 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 5 Oct 2023 08:13:22 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v10] In-Reply-To: References: Message-ID: On Thu, 5 Oct 2023 05:57:38 GMT, Thomas Stuefe wrote: > Looks good to me now, but Brian or Alan should okay this too. Yes, sure. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1748339213 From bpb at openjdk.org Thu Oct 5 14:55:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 5 Oct 2023 14:55:08 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v10] In-Reply-To: References: Message-ID: <_Z5HaH-Iwh9pcwunD3juODPS--31k5wy6UKFaImX9xs=.8cc253fe-1cdd-4fda-87ff-0c953205424d@github.com> On Thu, 5 Oct 2023 08:10:35 GMT, Severin Gehwolf wrote: > Looks good to me now, but Brian or Alan should okay this too. @AlanBateman is away this week so I would expect this review to continue into next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1749048096 From mbaesken at openjdk.org Thu Oct 5 15:21:54 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 5 Oct 2023 15:21:54 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages Message-ID: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. This leads sometimes to exceptions like MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] see https://bugs.openjdk.org/browse/JDK-8317307 It would be better to have a message explaining the reason instead of "no further information" . ------------- Commit messages: - JDK-8317603 Changes: https://git.openjdk.org/jdk/pull/16057/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317603 Stats: 23 lines in 1 file changed: 9 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/16057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16057/head:pull/16057 PR: https://git.openjdk.org/jdk/pull/16057 From djelinski at openjdk.org Thu Oct 5 16:16:28 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 5 Oct 2023 16:16:28 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Thu, 5 Oct 2023 14:33:14 GMT, Matthias Baesken wrote: > On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. > This leads sometimes to exceptions like > > MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] > > see https://bugs.openjdk.org/browse/JDK-8317307 > > It would be better to have a message explaining the reason instead of "no further information" . src/java.base/windows/native/libnio/ch/Net.c line 1: > 1: /* Thanks for this, the "no further information" message wasn't pretty. I'm not a fan of mixing styles, and this file uses `NET_ThrowNew` a lot. Can we choose either `NET_ThrowNew` or `handleSocketErrorMessage` and use in consistently everywhere? Also, the `NET_ThrowNew` messages usually list the function name only, without the `failed` suffix. Can we strip that suffix here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1347674947 From bpb at openjdk.org Thu Oct 5 20:18:44 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 5 Oct 2023 20:18:44 GMT Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with AccessDeniedException [v4] In-Reply-To: References: Message-ID: > The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8317128: Move read check outside replaceExisting c conditional ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15991/files - new: https://git.openjdk.org/jdk/pull/15991/files/299ffa51..e6028854 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15991&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15991&range=02-03 Stats: 8 lines in 1 file changed: 2 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15991/head:pull/15991 PR: https://git.openjdk.org/jdk/pull/15991 From lancea at openjdk.org Thu Oct 5 20:32:01 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 5 Oct 2023 20:32:01 GMT Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with AccessDeniedException [v4] In-Reply-To: References: Message-ID: On Thu, 5 Oct 2023 20:18:44 GMT, Brian Burkhalter wrote: >> The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8317128: Move read check outside replaceExisting c conditional looks Ok to me ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15991#pullrequestreview-1660654539 From alanb at openjdk.org Fri Oct 6 05:46:01 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Oct 2023 05:46:01 GMT Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with AccessDeniedException [v4] In-Reply-To: References: Message-ID: On Thu, 5 Oct 2023 20:18:44 GMT, Brian Burkhalter wrote: >> The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8317128: Move read check outside replaceExisting c conditional Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15991#pullrequestreview-1661148538 From mbaesken at openjdk.org Fri Oct 6 07:21:13 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 6 Oct 2023 07:21:13 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v2] In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com> > On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. > This leads sometimes to exceptions like > > MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] > > see https://bugs.openjdk.org/browse/JDK-8317307 > > It would be better to have a message explaining the reason instead of "no further information" . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: switch to NET_ThrowNew ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16057/files - new: https://git.openjdk.org/jdk/pull/16057/files/949309f7..70fb7f16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=00-01 Stats: 23 lines in 1 file changed: 0 ins; 7 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/16057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16057/head:pull/16057 PR: https://git.openjdk.org/jdk/pull/16057 From mbaesken at openjdk.org Fri Oct 6 07:21:14 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 6 Oct 2023 07:21:14 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Thu, 5 Oct 2023 14:33:14 GMT, Matthias Baesken wrote: > On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. > This leads sometimes to exceptions like > > MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] > > see https://bugs.openjdk.org/browse/JDK-8317307 > > It would be better to have a message explaining the reason instead of "no further information" . Hi Daniel, thanks for looking into it. I switched my calls to NET_ThrowNew and removed the 'failed' suffix of the message. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1750096508 From vtewari at openjdk.org Fri Oct 6 09:46:00 2023 From: vtewari at openjdk.org (Vyom Tewari) Date: Fri, 6 Oct 2023 09:46:00 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v2] In-Reply-To: <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com> Message-ID: On Fri, 6 Oct 2023 07:21:13 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > switch to NET_ThrowNew src/java.base/windows/native/libnio/ch/Net.c line 589: > 587: n = getsockopt(fdval(env, fdo), IPPROTO_IP, IP_MULTICAST_IF, (void*)&in, &arglen); > 588: if (n == SOCKET_ERROR) { > 589: NET_ThrowNew(env, WSAGetLastError(), "setsockopt"); there is typo, third argument should be "getsockopt" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1348460558 From djelinski at openjdk.org Fri Oct 6 09:46:00 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 6 Oct 2023 09:46:00 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v2] In-Reply-To: <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com> Message-ID: On Fri, 6 Oct 2023 07:21:13 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > switch to NET_ThrowNew src/java.base/windows/native/libnio/ch/Net.c line 732: > 730: } > 731: } else if (optError != NO_ERROR) { > 732: NET_ThrowNew(env, optError, "getsockopt"); This is not a `getsockopt` error, and using `"getsockopt"` here will make errors thrown here indistinguishable from errors thrown a few lines above. Can we use a different text? The errors here will usually be the result of async connect, but I'm not sure if that's guaranteed; `SO_ERROR` would probably be the safest choice, but it doesn't look pretty. I guess that's one of the places where "no further information" actually makes sense. Other than this, LGTM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1348390145 From mbaesken at openjdk.org Fri Oct 6 11:08:13 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 6 Oct 2023 11:08:13 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v3] In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com> > On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. > This leads sometimes to exceptions like > > MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] > > see https://bugs.openjdk.org/browse/JDK-8317307 > > It would be better to have a message explaining the reason instead of "no further information" . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust message texts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16057/files - new: https://git.openjdk.org/jdk/pull/16057/files/70fb7f16..c3b7e85d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16057/head:pull/16057 PR: https://git.openjdk.org/jdk/pull/16057 From mbaesken at openjdk.org Fri Oct 6 11:08:15 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 6 Oct 2023 11:08:15 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v2] In-Reply-To: <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> <7nPrsS-Qqz-RDjG6Tnwj451MjTDZNrFS87IDq132en0=.1ae6a201-f5fa-4619-90d0-fe2f864362c3@github.com> Message-ID: On Fri, 6 Oct 2023 07:21:13 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > switch to NET_ThrowNew Thanks, I adjusted the 2 messages mentioned . ------------- PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1750303763 From vtewari at openjdk.org Fri Oct 6 11:36:07 2023 From: vtewari at openjdk.org (Vyom Tewari) Date: Fri, 6 Oct 2023 11:36:07 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v3] In-Reply-To: <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com> Message-ID: On Fri, 6 Oct 2023 11:08:13 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust message texts Looks OK to me. ------------- Marked as reviewed by vtewari (Committer). PR Review: https://git.openjdk.org/jdk/pull/16057#pullrequestreview-1661674427 From mbaesken at openjdk.org Fri Oct 6 13:39:45 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 6 Oct 2023 13:39:45 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v3] In-Reply-To: <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com> Message-ID: On Fri, 6 Oct 2023 11:08:13 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust message texts Thanks for the review ! Daniel , are you okay with the latest version ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1750695930 From alanb at openjdk.org Fri Oct 6 13:59:40 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Oct 2023 13:59:40 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v3] In-Reply-To: <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com> Message-ID: On Fri, 6 Oct 2023 11:08:13 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust message texts I plan to review this as I think we'll need to do a few other changes as part of this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1750724507 From jvernee at openjdk.org Fri Oct 6 16:12:57 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 6 Oct 2023 16:12:57 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v34] In-Reply-To: References: Message-ID: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits: - fix failing RestrictedMethods test - Merge branch 'master' into JEP22 - Remove PIP annotation from jdk.incubator.vector - review @enablePreview from java/foreign/TestRestricted test - Merge branch 'master' into JEP22 - drop unneeded @compile tags from jtreg tests - Use IAE instead of UOE for unsupported char sets - Use abort instead of IEA when encountering wrong value for ENA attrib. - Fix visibility issues Reviewed-by: mcimadamore - Review comments - ... and 53 more: https://git.openjdk.org/jdk/compare/b3cc0c84...b4a7b7ab ------------- Changes: https://git.openjdk.org/jdk/pull/15103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=33 Stats: 4361 lines in 263 files changed: 2211 ins; 1196 del; 954 mod Patch: https://git.openjdk.org/jdk/pull/15103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103 PR: https://git.openjdk.org/jdk/pull/15103 From jvernee at openjdk.org Fri Oct 6 16:13:33 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 6 Oct 2023 16:13:33 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v33] In-Reply-To: <0r5bNt-ez79b7DrOJUuHCPguBQkn3MtEJdoQFqVuWxA=.86265508-9e7d-4fab-a851-35c5c138255d@github.com> References: <0r5bNt-ez79b7DrOJUuHCPguBQkn3MtEJdoQFqVuWxA=.86265508-9e7d-4fab-a851-35c5c138255d@github.com> Message-ID: On Mon, 2 Oct 2023 16:07:09 GMT, Jorn Vernee wrote: >> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: >> >> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. >> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. >> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. >> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. >> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. >> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) >> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. >> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. >> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedO... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Remove PIP annotation from jdk.incubator.vector I've addressed one more test failure in [b4a7b7a](https://github.com/openjdk/jdk/pull/15103/commits/b4a7b7abe75aee72c8e56c12c0ddbeb597e15f1b) that was found after merging this patch with the most recent master branch. The test in questions checks for linter warnings for restricted methods. It depends on the FFM API for that, which is still preview in the master branch, but no longer preview as part of this patch. Hence the warnings the compiler outputs is different, and the test fails. I've fixed to test. The preview flags are no longer needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1751015355 From bpb at openjdk.org Fri Oct 6 17:49:30 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 6 Oct 2023 17:49:30 GMT Subject: Integrated: 8317128: java/nio/file/Files/CopyAndMove.java failed with AccessDeniedException In-Reply-To: References: Message-ID: On Fri, 29 Sep 2023 15:57:48 GMT, Brian Burkhalter wrote: > The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE. This pull request has now been integrated. Changeset: 6c6beba2 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/6c6beba2569a2f9f3fd5d6988360ffd8680de821 Stats: 29 lines in 2 files changed: 15 ins; 11 del; 3 mod 8317128: java/nio/file/Files/CopyAndMove.java failed with AccessDeniedException Reviewed-by: alanb, lancea ------------- PR: https://git.openjdk.org/jdk/pull/15991 From bpb at openjdk.org Fri Oct 6 21:49:31 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 6 Oct 2023 21:49:31 GMT Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView(posix) incorrectly returns 'true' for FAT32 volume on macOS Message-ID: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32. ------------- Commit messages: - 8317687: (fs) FileStore.supportsFileAttributeView(posix) incorrectly returns 'true' for FAT32 volume on macOS Changes: https://git.openjdk.org/jdk/pull/16084/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16084&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317687 Stats: 32 lines in 2 files changed: 27 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16084/head:pull/16084 PR: https://git.openjdk.org/jdk/pull/16084 From bpb at openjdk.org Fri Oct 6 21:49:31 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 6 Oct 2023 21:49:31 GMT Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView(posix) incorrectly returns 'true' for FAT32 volume on macOS In-Reply-To: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> Message-ID: On Fri, 6 Oct 2023 21:39:32 GMT, Brian Burkhalter wrote: > Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32. This change also exposed a problem in the `java/nio/file/Files/CopyAndMove.java` test which failed in `CopyAndMove.checkBasicAttributes` due to the source and destination last modified time stamps not being equal. This was due to FAT32 volumes having only a resolution of 2 seconds for the write time. The test is incidentally modified to allow an offset of no more than 2 seconds in this case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16084#issuecomment-1751434290 From alanb at openjdk.org Sat Oct 7 06:25:56 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 7 Oct 2023 06:25:56 GMT Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix") incorrectly returns 'true' for FAT32 volume on macOS In-Reply-To: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> Message-ID: On Fri, 6 Oct 2023 21:39:32 GMT, Brian Burkhalter wrote: > Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32. src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 107: > 105: if (type == PosixFileAttributeView.class && > 106: entry().fstype().equals("msdos")) > 107: return false; I suspect supportsFileAttributeView(String) will need to be changed to return false if the view name is "unix". test/jdk/java/nio/file/Files/CopyAndMove.java line 158: > 156: attrs1.fileKey(), attrs1.lastModifiedTime()); > 157: System.err.format("File time for %s is %s\n", > 158: attrs2.fileKey(), attrs2.lastModifiedTime()); Are you 150% sure this is reliable? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1349471509 PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1349471986 From alanb at openjdk.org Sat Oct 7 12:47:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 7 Oct 2023 12:47:06 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v3] In-Reply-To: <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com> Message-ID: On Fri, 6 Oct 2023 11:08:13 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust message texts Moving to using NET_ThrowNew is okay but it creates inconsistencies that have to be fixed. I think this PR will go through a few iterations. Some background here is that the socket code no longer exists in libnet/net.dll and at some point we need to do some cleanup and refactoring so that libnio does not have libnet as a dependency (if you go through the JBS issue you'll see a number of startup/first-use issues caused by this dependency). We don't have to do this as part of this PR of course but it provides some context. For this PR, the issue with changing the specific functions to use NET_ThrowNet is that handleSocketError is left in place for DatagramChannelImpl.c, IOUtil.c and UnixDomainSocket.c. We shouldn't do that. We either replace usages (and remove handleSocketError) or change the existing function to take an additional message. src/java.base/windows/native/libnio/ch/Net.c line 559: > 557: int n = setGroupSourceReqOption(env, fdo, opt, group, index, source); > 558: if (n == SOCKET_ERROR) { > 559: NET_ThrowNew(env, WSAGetLastError(), "setsockopt with group source request"); That message looks odd, I think you want "setsocketopt to block or unblock source". src/java.base/windows/native/libnio/ch/Net.c line 638: > 636: int count = 0; > 637: if (NET_SocketAvailable(fdval(env, fdo), &count) != 0) { > 638: NET_ThrowNew(env, WSAGetLastError(), "socket availability check"); This should be "ioctlsocket", not ""socket availability check". Better still would be to just replace the usage of NET_SocketAvailable to use ioctlsocket directly as we will eventually remove NET_SocketAvailable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1751703045 PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1349516548 PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1349516493 From alanb at openjdk.org Sat Oct 7 13:01:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 7 Oct 2023 13:01:16 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v10] In-Reply-To: References: Message-ID: On Wed, 4 Oct 2023 19:15:01 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Add missing returns when statx is available test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96: > 94: System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead); > 95: // Creation time updates are not supported on Linux > 96: supportsCreationTimeWrite = false; It might be simpler to use `Linker.nativeLinker().defaultLookup().find("statx").isPresent()` as that would avoid adding CreationTimeHelper. JEP 454 is proposed to target 22 so the test won't need @enablePreview. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1349518168 From alanb at openjdk.org Sat Oct 7 13:13:17 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 7 Oct 2023 13:13:17 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v10] In-Reply-To: References: Message-ID: <3yg6BZX9C1esvVPAFmGt60AykzyDj7PQeZ27weyyOTE=.bd37a111-0a6c-462a-b92c-4aa40363d02f@github.com> On Wed, 4 Oct 2023 19:15:01 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Add missing returns when statx is available src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 281: > 279: int follow_symlink) { > 280: if (follow_symlink == NO_FOLLOW_SYMLINK) { > 281: flags |= AT_SYMLINK_NOFOLLOW; I think it would be better if statx_wrapper had the same signature as statx. Have you tried adding the AT_SYMLINK_NOFOLLOW flag at the use-site? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1349519444 From alanb at openjdk.org Sat Oct 7 13:16:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 7 Oct 2023 13:16:07 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v10] In-Reply-To: References: Message-ID: On Wed, 4 Oct 2023 19:15:01 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Add missing returns when statx is available The additions to UnixNativeDispatcher looks okay, I'd just prefer for statx_wrapper to have the same sig as statx if possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1751709969 From sgehwolf at openjdk.org Mon Oct 9 10:08:17 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 9 Oct 2023 10:08:17 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v10] In-Reply-To: References: Message-ID: On Sat, 7 Oct 2023 12:58:17 GMT, Alan Bateman wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing returns when statx is available > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96: > >> 94: System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead); >> 95: // Creation time updates are not supported on Linux >> 96: supportsCreationTimeWrite = false; > > It might be simpler to use `Linker.nativeLinker().defaultLookup().find("statx").isPresent()` as that would avoid adding CreationTimeHelper. JEP 454 is proposed to target 22 so the test won't need @enablePreview. OK. If I use that this patch will have to wait for https://github.com/openjdk/jdk/pull/15103 to get integrated before this can be merged (avoiding the need to add `@enablePreview`). But that should happen fairly soon so it should be fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350058442 From sgehwolf at openjdk.org Mon Oct 9 10:27:09 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 9 Oct 2023 10:27:09 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v10] In-Reply-To: <3yg6BZX9C1esvVPAFmGt60AykzyDj7PQeZ27weyyOTE=.bd37a111-0a6c-462a-b92c-4aa40363d02f@github.com> References: <3yg6BZX9C1esvVPAFmGt60AykzyDj7PQeZ27weyyOTE=.bd37a111-0a6c-462a-b92c-4aa40363d02f@github.com> Message-ID: On Sat, 7 Oct 2023 13:09:53 GMT, Alan Bateman wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing returns when statx is available > > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 281: > >> 279: int follow_symlink) { >> 280: if (follow_symlink == NO_FOLLOW_SYMLINK) { >> 281: flags |= AT_SYMLINK_NOFOLLOW; > > I think it would be better if statx_wrapper had the same signature as statx. Have you tried adding the AT_SYMLINK_NOFOLLOW flag at the use-site? Sure, I can do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350115255 From sgehwolf at openjdk.org Mon Oct 9 10:27:11 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 9 Oct 2023 10:27:11 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v10] In-Reply-To: References: Message-ID: On Mon, 9 Oct 2023 09:25:55 GMT, Severin Gehwolf wrote: >> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96: >> >>> 94: System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead); >>> 95: // Creation time updates are not supported on Linux >>> 96: supportsCreationTimeWrite = false; >> >> It might be simpler to use `Linker.nativeLinker().defaultLookup().find("statx").isPresent()` as that would avoid adding CreationTimeHelper. JEP 454 is proposed to target 22 so the test won't need @enablePreview. > > OK. If I use that this patch will have to wait for https://github.com/openjdk/jdk/pull/15103 to get integrated before this can be merged (avoiding the need to add `@enablePreview`). But that should happen fairly soon so it should be fine. For now I'm still using `@enablePreview` and will drop before integration once it's ready. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350119526 From mbaesken at openjdk.org Mon Oct 9 10:31:01 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 9 Oct 2023 10:31:01 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v4] In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: <3CERRSFZlqfnqs98NVNF23znQliGdMtBPqff3GhnHsI=.87b05e01-3711-4121-acc1-e6e4ea536acf@github.com> > On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. > This leads sometimes to exceptions like > > MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] > > see https://bugs.openjdk.org/browse/JDK-8317307 > > It would be better to have a message explaining the reason instead of "no further information" . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: replace windows handleSocketError ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16057/files - new: https://git.openjdk.org/jdk/pull/16057/files/c3b7e85d..d5137560 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=02-03 Stats: 27 lines in 5 files changed: 9 ins; 8 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/16057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16057/head:pull/16057 PR: https://git.openjdk.org/jdk/pull/16057 From mbaesken at openjdk.org Mon Oct 9 10:31:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 9 Oct 2023 10:31:02 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v3] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> <564SLXjanlbP6G_LJ0o9MulfgyVbv2FKFRfRiyzeZ30=.88d36cfe-c09c-46e8-a21c-67c5c64ba12c@github.com> Message-ID: On Sat, 7 Oct 2023 12:41:31 GMT, Alan Bateman wrote: > Moving to using NET_ThrowNew is okay but it creates inconsistencies that have to be fixed. I think this PR will go through a few iterations. > > Some background here is that the socket code no longer exists in libnet/net.dll and at some point we need to do some cleanup and refactoring so that libnio does not have libnet as a dependency (if you go through the JBS issue you'll see a number of startup/first-use issues caused by this dependency). We don't have to do this as part of this PR of course but it provides some context. > > For this PR, the issue with changing the specific functions to use NET_ThrowNet is that handleSocketError is left in place for DatagramChannelImpl.c, IOUtil.c and UnixDomainSocket.c. We shouldn't do that. We either replace usages (and remove handleSocketError) or change the existing function to take an additional message. Okay, let's remove then the usages in the files you mentioned. > src/java.base/windows/native/libnio/ch/Net.c line 559: > >> 557: int n = setGroupSourceReqOption(env, fdo, opt, group, index, source); >> 558: if (n == SOCKET_ERROR) { >> 559: NET_ThrowNew(env, WSAGetLastError(), "setsockopt with group source request"); > > That message looks odd, I think you want "setsocketopt to block or unblock source". Thanks, I adjusted the message. > src/java.base/windows/native/libnio/ch/Net.c line 638: > >> 636: int count = 0; >> 637: if (NET_SocketAvailable(fdval(env, fdo), &count) != 0) { >> 638: NET_ThrowNew(env, WSAGetLastError(), "socket availability check"); > > This should be "ioctlsocket", not ""socket availability check". Better still would be to just replace the usage of NET_SocketAvailable to use ioctlsocket directly as we will eventually remove NET_SocketAvailable. okay then let's use ioctlsocket . We could completely remove NET_SocketAvailable. but in a follow up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1752712706 PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1350097325 PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1350098133 From mbaesken at openjdk.org Mon Oct 9 11:54:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 9 Oct 2023 11:54:55 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v5] In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: > On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. > This leads sometimes to exceptions like > > MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] > > see https://bugs.openjdk.org/browse/JDK-8317307 > > It would be better to have a message explaining the reason instead of "no further information" . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: add missing quotation mark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16057/files - new: https://git.openjdk.org/jdk/pull/16057/files/d5137560..073a555c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16057/head:pull/16057 PR: https://git.openjdk.org/jdk/pull/16057 From sgehwolf at openjdk.org Mon Oct 9 13:12:58 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 9 Oct 2023 13:12:58 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v11] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: - Keep wrapper function signature compatible to statx - Refactor test so as to use Linker from JEP 454. @enablePreview still needed as of yet. This can go once JDK-8312522 integrates. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/ad428030..1c4cac36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=09-10 Stats: 86 lines in 5 files changed: 2 ins; 76 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From sgehwolf at openjdk.org Mon Oct 9 13:13:00 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 9 Oct 2023 13:13:00 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v10] In-Reply-To: References: Message-ID: <5q7w0cmemjP6uyVSBSwKUxFFW7i7ucquIFq6GByRkcE=.5245ec21-cb80-4d15-b735-f4b8db4df436@github.com> On Sat, 7 Oct 2023 13:13:15 GMT, Alan Bateman wrote: > The additions to UnixNativeDispatcher looks okay, I'd just prefer for statx_wrapper to have the same sig as statx if possible. All remaining issues should have been addressed in the latest version (modulo `@enablePreview`). ------------- PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1752979449 From sgehwolf at openjdk.org Mon Oct 9 13:13:01 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 9 Oct 2023 13:13:01 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v11] In-Reply-To: References: Message-ID: On Mon, 9 Oct 2023 13:07:15 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: > > - Keep wrapper function signature compatible to statx > - Refactor test so as to use Linker from JEP 454. > > @enablePreview still needed as of yet. This can go once > JDK-8312522 integrates. test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 30: > 28: * @library ../.. /test/lib > 29: * @build jdk.test.lib.Platform > 30: * @enablePreview FYI: This line won't be pushed as without it the test fails (currently). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350284105 From bpb at openjdk.org Mon Oct 9 17:08:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Oct 2023 17:08:53 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v5] In-Reply-To: References: Message-ID: > Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. 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 seven additional commits since the last revision: - Merge - 4860681: Heap and direct buffer specializations - 4860681: Change some {@code ...} to ... to prevent line breaking - 4860681: Modify existing test - Merge - 4860681: Add spaces to parameter lists in @see tag - 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13744/files - new: https://git.openjdk.org/jdk/pull/13744/files/9e1ce482..90eee4e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=03-04 Stats: 276664 lines in 5667 files changed: 118687 ins; 101301 del; 56676 mod Patch: https://git.openjdk.org/jdk/pull/13744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13744/head:pull/13744 PR: https://git.openjdk.org/jdk/pull/13744 From bpb at openjdk.org Mon Oct 9 17:55:57 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Oct 2023 17:55:57 GMT Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix") incorrectly returns 'true' for FAT32 volume on macOS In-Reply-To: References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> Message-ID: On Sat, 7 Oct 2023 06:22:50 GMT, Alan Bateman wrote: >> Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32. > > test/jdk/java/nio/file/Files/CopyAndMove.java line 158: > >> 156: attrs1.fileKey(), attrs1.lastModifiedTime()); >> 157: System.err.format("File time for %s is %s\n", >> 158: attrs2.fileKey(), attrs2.lastModifiedTime()); > > Are you 150% sure this is reliable? According to [1], "[...] the resolution of create time on FAT is 10 milliseconds, while write time has a resolution of 2 seconds and access time has a resolution of 1 day [...]" where "write time" is "last modified time." The testing I have done has thus far borne this out. [1] [File Times](https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1350621134 From bpb at openjdk.org Mon Oct 9 18:04:05 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Oct 2023 18:04:05 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v5] In-Reply-To: References: Message-ID: On Mon, 9 Oct 2023 17:08:53 GMT, Brian Burkhalter wrote: >> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. > > 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 seven additional commits since the last revision: > > - Merge > - 4860681: Heap and direct buffer specializations > - 4860681: Change some {@code ...} to ... to prevent line breaking > - 4860681: Modify existing test > - Merge > - 4860681: Add spaces to parameter lists in @see tag > - 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence Ping ------------- PR Comment: https://git.openjdk.org/jdk/pull/13744#issuecomment-1753432152 From alanb at openjdk.org Mon Oct 9 18:38:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 9 Oct 2023 18:38:06 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v11] In-Reply-To: References: Message-ID: On Mon, 9 Oct 2023 13:12:58 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: > > - Keep wrapper function signature compatible to statx > - Refactor test so as to use Linker from JEP 454. > > @enablePreview still needed as of yet. This can go once > JDK-8312522 integrates. The update to UnixNativeDispatcher.c looks okay now. test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 30: > 28: * @library ../.. /test/lib > 29: * @build jdk.test.lib.Platform > 30: * @enablePreview It doesn't matter but I think the convention is to put `@enablePreview` before `@library` and `@build`. test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96: > 94: // Creation time read depends on statx system call support > 95: supportsCreationTimeRead = Linker.nativeLinker().defaultLookup().find("statx").isPresent(); > 96: System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead); I think you left a debug statement here, or if you didn't then maybe drop the work "Debug" as it looks out of place here. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1665083160 PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350674479 PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1350675005 From alanb at openjdk.org Mon Oct 9 18:41:03 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 9 Oct 2023 18:41:03 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v5] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Mon, 9 Oct 2023 11:54:55 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add missing quotation mark src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c line 92: > 90: rv = connect((SOCKET)fd, &sa.sa, sa_len); > 91: if (rv == SOCKET_ERROR) { > 92: NET_ThrowNew(env, WSAGetLastError(), "connect"); Can you check the copyright date on this and the other files as some of these haven't been updated in a while. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1350680210 From alanb at openjdk.org Mon Oct 9 18:46:02 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 9 Oct 2023 18:46:02 GMT Subject: RFR: JDK-8317603: provide handleSocketErrorWithMessage in windows Net.c for extended exception messages [v5] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Mon, 9 Oct 2023 11:54:55 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add missing quotation mark So I think this version looks okay. We should probably rename the JBS issue and the PR as the change is no longer a handleSocketWithMessage function. src/java.base/windows/native/libnio/ch/Net.c line 556: > 554: NET_ThrowNew(env, WSAGetLastError(), "setsocketopt to block source"); > 555: } else { > 556: NET_ThrowNew(env, WSAGetLastError(), "setsocketopt to unblock source"); I think this can be reduced to one message (block or unblock) source as it doesn't add value as the stack trace will make it very clear if a source-specific block or unblock op. src/java.base/windows/native/libnio/ch/Net.c line 636: > 634: u_long arg; > 635: if (ioctlsocket((SOCKET) fdval(env, fdo), FIONREAD, &arg) == SOCKET_ERROR) { > 636: NET_ThrowNew(env, WSAGetLastError(), "ioctlsocket"); Thanks for doing this, we should have removed the use of NET_SocketAvailable here a long time ago (same thing in the Unix code). ------------- PR Review: https://git.openjdk.org/jdk/pull/16057#pullrequestreview-1665094335 PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1350683877 PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1350684981 From bpb at openjdk.org Mon Oct 9 19:00:02 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Oct 2023 19:00:02 GMT Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix") incorrectly returns 'true' for FAT32 volume on macOS [v2] In-Reply-To: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> Message-ID: > Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8317687: Return false for "unix" view of FAT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16084/files - new: https://git.openjdk.org/jdk/pull/16084/files/ff938a04..0cc942c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16084&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16084&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16084/head:pull/16084 PR: https://git.openjdk.org/jdk/pull/16084 From bpb at openjdk.org Mon Oct 9 19:00:05 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Oct 2023 19:00:05 GMT Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix") incorrectly returns 'true' for FAT32 volume on macOS [v2] In-Reply-To: References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> Message-ID: On Sat, 7 Oct 2023 06:22:20 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8317687: Return false for "unix" view of FAT > > src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 107: > >> 105: if (type == PosixFileAttributeView.class && >> 106: entry().fstype().equals("msdos")) >> 107: return false; > > I suspect supportsFileAttributeView(String) will need to be changed to return false if the view name is "unix". Yes. Changed in 0cc942c2c3d888cf90f7fcc0dd8fb6c50de616cf. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1350697416 From bpb at openjdk.org Mon Oct 9 19:38:02 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Oct 2023 19:38:02 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v11] In-Reply-To: References: Message-ID: On Mon, 9 Oct 2023 13:12:58 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: > > - Keep wrapper function signature compatible to statx > - Refactor test so as to use Linker from JEP 454. > > @enablePreview still needed as of yet. This can go once > JDK-8312522 integrates. Nice to see the test C code gone. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1665154207 From rriggs at openjdk.org Mon Oct 9 20:47:06 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 9 Oct 2023 20:47:06 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v5] In-Reply-To: References: Message-ID: On Mon, 9 Oct 2023 17:08:53 GMT, Brian Burkhalter wrote: >> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. > > 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 seven additional commits since the last revision: > > - Merge > - 4860681: Heap and direct buffer specializations > - 4860681: Change some {@code ...} to ... to prevent line breaking > - 4860681: Modify existing test > - Merge > - 4860681: Add spaces to parameter lists in @see tag > - 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence The API spec for put looks fine. src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 542: > 540: sb.getChars(start, start + count, buf, 0); > 541: } else if (csq instanceof StringBuffer sb) { > 542: sb.getChars(start, start + count, buf, 0); Can the allocation and double copy be avoided? But I guess the combinatorics of latin1/utf16 string encoding and the memory and byte order make it difficult. test/jdk/java/nio/Buffer/Basic-X.java.template line 636: > 634: long seed = System.nanoTime(); > 635: Random rnd = new Random(seed); > 636: Printing the seed would make it possible to repeat the same test. ------------- PR Review: https://git.openjdk.org/jdk/pull/13744#pullrequestreview-1665197849 PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1350764882 PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1350754116 From bpb at openjdk.org Mon Oct 9 21:19:37 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Oct 2023 21:19:37 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v6] In-Reply-To: References: Message-ID: > Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4860681: Make test use RandomFactory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13744/files - new: https://git.openjdk.org/jdk/pull/13744/files/90eee4e9..2ea96eed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=04-05 Stats: 23 lines in 2 files changed: 9 ins; 9 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13744/head:pull/13744 PR: https://git.openjdk.org/jdk/pull/13744 From bpb at openjdk.org Mon Oct 9 21:19:44 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Oct 2023 21:19:44 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v5] In-Reply-To: References: Message-ID: On Mon, 9 Oct 2023 20:31:41 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge >> - 4860681: Heap and direct buffer specializations >> - 4860681: Change some {@code ...} to ... to prevent line breaking >> - 4860681: Modify existing test >> - Merge >> - 4860681: Add spaces to parameter lists in @see tag >> - 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence > > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 542: > >> 540: sb.getChars(start, start + count, buf, 0); >> 541: } else if (csq instanceof StringBuffer sb) { >> 542: sb.getChars(start, start + count, buf, 0); > > Can the allocation and double copy be avoided? > But I guess the combinatorics of latin1/utf16 string encoding and the memory and byte order make it difficult. Back when I was originally developing this change I could not see any better way to do this part. > test/jdk/java/nio/Buffer/Basic-X.java.template line 636: > >> 634: long seed = System.nanoTime(); >> 635: Random rnd = new Random(seed); >> 636: > > Printing the seed would make it possible to repeat the same test. So modified in 2ea96eed0bba75e1126ede5de31ebbb05950d663. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1350793218 PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1350792811 From mbaesken at openjdk.org Tue Oct 10 07:57:46 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 10 Oct 2023 07:57:46 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v6] In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: > On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. > This leads sometimes to exceptions like > > MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] > > see https://bugs.openjdk.org/browse/JDK-8317307 > > It would be better to have a message explaining the reason instead of "no further information" . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: COPYRIGHT headers and minor adjustments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16057/files - new: https://git.openjdk.org/jdk/pull/16057/files/073a555c..2fe42bd9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=04-05 Stats: 9 lines in 5 files changed: 0 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16057/head:pull/16057 PR: https://git.openjdk.org/jdk/pull/16057 From mbaesken at openjdk.org Tue Oct 10 07:57:49 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 10 Oct 2023 07:57:49 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v5] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Mon, 9 Oct 2023 11:54:55 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add missing quotation mark Hi reviewers , are you fine with the latest version ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1754612245 From mbaesken at openjdk.org Tue Oct 10 07:57:53 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 10 Oct 2023 07:57:53 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v5] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Mon, 9 Oct 2023 18:38:12 GMT, Alan Bateman wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> add missing quotation mark > > src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c line 92: > >> 90: rv = connect((SOCKET)fd, &sa.sa, sa_len); >> 91: if (rv == SOCKET_ERROR) { >> 92: NET_ThrowNew(env, WSAGetLastError(), "connect"); > > Can you check the copyright date on this and the other files as some of these haven't been updated in a while. Hi Alan, I adjusted the copyright dates. > src/java.base/windows/native/libnio/ch/Net.c line 556: > >> 554: NET_ThrowNew(env, WSAGetLastError(), "setsocketopt to block source"); >> 555: } else { >> 556: NET_ThrowNew(env, WSAGetLastError(), "setsocketopt to unblock source"); > > I think this can be reduced to one message (block or unblock) source as it doesn't add value as the stack trace will make it very clear if a source-specific block or unblock op. Okay, I reduced it to one message. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1351755006 PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1351756715 From alanb at openjdk.org Tue Oct 10 08:23:00 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 10 Oct 2023 08:23:00 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v6] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Tue, 10 Oct 2023 07:57:46 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > COPYRIGHT headers and minor adjustments src/java.base/windows/native/libnio/ch/Net.c line 726: > 724: } > 725: } else if (optError != NO_ERROR) { > 726: NET_ThrowNew(env, optError, "getsockopt issue with option value"); I assume "getsockopt issue with option value" should be "getsockopt" here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1351844096 From sgehwolf at openjdk.org Tue Oct 10 08:26:04 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 10 Oct 2023 08:26:04 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v11] In-Reply-To: References: Message-ID: On Mon, 9 Oct 2023 13:12:58 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: > > - Keep wrapper function signature compatible to statx > - Refactor test so as to use Linker from JEP 454. > > @enablePreview still needed as of yet. This can go once > JDK-8312522 integrates. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1754677186 From sgehwolf at openjdk.org Tue Oct 10 08:26:09 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 10 Oct 2023 08:26:09 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v11] In-Reply-To: References: Message-ID: On Mon, 9 Oct 2023 18:33:41 GMT, Alan Bateman wrote: >> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: >> >> - Keep wrapper function signature compatible to statx >> - Refactor test so as to use Linker from JEP 454. >> >> @enablePreview still needed as of yet. This can go once >> JDK-8312522 integrates. > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 30: > >> 28: * @library ../.. /test/lib >> 29: * @build jdk.test.lib.Platform >> 30: * @enablePreview > > It doesn't matter but I think the convention is to put `@enablePreview` before `@library` and `@build`. This shouldn't matter indeed as I intend to push only once #15103 is pushed not needing the `@enablePreview` annotation. > test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96: > >> 94: // Creation time read depends on statx system call support >> 95: supportsCreationTimeRead = Linker.nativeLinker().defaultLookup().find("statx").isPresent(); >> 96: System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead); > > I think you left a debug statement here, or if you didn't then maybe drop the work "Debug" as it looks out of place here. I can drop the `Debug` word, but would like to keep the rest as the test behaves differently whether or not `supportsCreationTimeRead` is true or not. On a `statx`-supporting system it would check that the modified time is different from the creation time. Otherwise it wouldn't. So it's nice to know which mode the test ran in. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1351848302 PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1351843932 From alanb at openjdk.org Tue Oct 10 08:27:01 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 10 Oct 2023 08:27:01 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v6] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Tue, 10 Oct 2023 07:57:46 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > COPYRIGHT headers and minor adjustments src/java.base/windows/native/libnio/ch/Net.c line 541: > 539: > 540: if (n == SOCKET_ERROR) { > 541: NET_ThrowNew(env, WSAGetLastError(), error_message); I this this one can be simplified to "setsockopt". Source-specific multicast isn't widely used but if you did happen to get a failure here then the stack trace should make it very clear as it's a different join method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1351849380 From sgehwolf at openjdk.org Tue Oct 10 08:31:50 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 10 Oct 2023 08:31:50 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v12] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Drop word 'Debug:' in CreationTime test code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/1c4cac36..cdd0fd54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From alanb at openjdk.org Tue Oct 10 08:33:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 10 Oct 2023 08:33:11 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v11] In-Reply-To: References: Message-ID: On Tue, 10 Oct 2023 08:20:28 GMT, Severin Gehwolf wrote: >> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 96: >> >>> 94: // Creation time read depends on statx system call support >>> 95: supportsCreationTimeRead = Linker.nativeLinker().defaultLookup().find("statx").isPresent(); >>> 96: System.out.println("[Linux] Debug: supportsCreationTimeRead == " + supportsCreationTimeRead); >> >> I think you left a debug statement here, or if you didn't then maybe drop the work "Debug" as it looks out of place here. > > I can drop the `Debug` word, but would like to keep the rest as the test behaves differently whether or not `supportsCreationTimeRead` is true or not. On a `statx`-supporting system it would check that the modified time is different from the creation time. Otherwise it wouldn't. So it's nice to know which mode the test ran in. If you do leave a trace message here then better to put it after the if-then-else so that it's clear on all platforms whether file create time is tested or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1351858240 From sgehwolf at openjdk.org Tue Oct 10 08:38:06 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 10 Oct 2023 08:38:06 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v11] In-Reply-To: References: Message-ID: On Tue, 10 Oct 2023 08:30:22 GMT, Alan Bateman wrote: >> I can drop the `Debug` word, but would like to keep the rest as the test behaves differently whether or not `supportsCreationTimeRead` is true or not. On a `statx`-supporting system it would check that the modified time is different from the creation time. Otherwise it wouldn't. So it's nice to know which mode the test ran in. > > If you do leave a trace message here then better to put it after the if-then-else so that it's clear on all platforms whether file create time is tested or not. OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1351863494 From sgehwolf at openjdk.org Tue Oct 10 08:44:49 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 10 Oct 2023 08:44:49 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v13] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Move trace message after platform specific blocks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/cdd0fd54..cbb24e38 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=11-12 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From alanb at openjdk.org Tue Oct 10 09:03:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 10 Oct 2023 09:03:06 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v13] In-Reply-To: References: Message-ID: <66OrTFZaXxlst-TvipIRxzw1oEQU7n7qZvF8hvSQpOA=.c8a61f50-e05d-4069-91cf-21c454835f07@github.com> On Tue, 10 Oct 2023 08:44:49 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Move trace message after platform specific blocks Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1666959450 From mbaesken at openjdk.org Tue Oct 10 09:24:37 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 10 Oct 2023 09:24:37 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v7] In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: > On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. > This leads sometimes to exceptions like > > MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] > > see https://bugs.openjdk.org/browse/JDK-8317307 > > It would be better to have a message explaining the reason instead of "no further information" . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust some messages ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16057/files - new: https://git.openjdk.org/jdk/pull/16057/files/2fe42bd9..a4175aa1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=05-06 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16057/head:pull/16057 PR: https://git.openjdk.org/jdk/pull/16057 From mbaesken at openjdk.org Tue Oct 10 09:24:37 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 10 Oct 2023 09:24:37 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v6] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Tue, 10 Oct 2023 07:57:46 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > COPYRIGHT headers and minor adjustments Hi Alan, I simplified the 2 messages. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1754794433 From alanb at openjdk.org Tue Oct 10 09:48:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 10 Oct 2023 09:48:15 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v7] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Tue, 10 Oct 2023 09:24:37 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust some messages Marked as reviewed by alanb (Reviewer). src/java.base/windows/native/libnio/ch/Net.c line 536: > 534: int opt = (join) ? MCAST_JOIN_SOURCE_GROUP : MCAST_LEAVE_SOURCE_GROUP; > 535: n = setGroupSourceReqOption(env, fdo, opt, group, index, source); > 536: I assume this blank line isn't needed now. src/java.base/windows/native/libnio/ch/Net.c line 552: > 550: int n = setGroupSourceReqOption(env, fdo, opt, group, index, source); > 551: if (n == SOCKET_ERROR) { > 552: NET_ThrowNew(env, WSAGetLastError(), "setsocketopt to block or unblock source"); This message is okay although it can be reduced to "setsockopt" to be consistent with the others. If source filtering is used then the stack trace will be very clear if a source address is being blocked or unblocked. ------------- PR Review: https://git.openjdk.org/jdk/pull/16057#pullrequestreview-1667076159 PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1352035707 PR Review Comment: https://git.openjdk.org/jdk/pull/16057#discussion_r1352039763 From mbaesken at openjdk.org Tue Oct 10 11:32:16 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 10 Oct 2023 11:32:16 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v8] In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: > On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. > This leads sometimes to exceptions like > > MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] > > see https://bugs.openjdk.org/browse/JDK-8317307 > > It would be better to have a message explaining the reason instead of "no further information" . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: remove blank line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16057/files - new: https://git.openjdk.org/jdk/pull/16057/files/a4175aa1..524285d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16057&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16057/head:pull/16057 PR: https://git.openjdk.org/jdk/pull/16057 From bpb at openjdk.org Tue Oct 10 14:52:54 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Oct 2023 14:52:54 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v13] In-Reply-To: References: Message-ID: On Tue, 10 Oct 2023 08:44:49 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Move trace message after platform specific blocks +1 ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1667982626 From djelinski at openjdk.org Tue Oct 10 18:18:15 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 10 Oct 2023 18:18:15 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v8] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: <65RyYOEpbHNKfQI3PB_hoquyN0YPKyUq2YDxka1Bonk=.746b3a0b-231f-4f49-963f-afe884f50fef@github.com> On Tue, 10 Oct 2023 11:32:16 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove blank line Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16057#pullrequestreview-1668536894 From brian.burkhalter at oracle.com Tue Oct 10 18:31:15 2023 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 10 Oct 2023 18:31:15 +0000 Subject: [Request for Comments] File extension redux Message-ID: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com> I would like to resurrect this topic which has languished for quite a while now. It was discussed for probably decades before my involvement with it. A brief outline of its most recent history is included below. The essence is that it would be good to add a java.nio.file.Path.getExtension method, and possibly one or more companion methods. General comments on the topic are welcome regardless of whether the included chronology is reviewed. Things to consider include: 1) whether a getExtension method ever returns null; 2) whether a period character is included as the first character of the returned extension; 3) whether the extension of ?foo? (no dot) differs from that of ?foo.? (terminal dot). Thanks, Brian --- snip --- TL;DR --- snip --- [1] Feb. 2018 Path.hasExtension was initially proposed but dropped in favor of Path.getExtension. This method was for the most common cases equivalent to Path path = ...; String name = path.getFileName(); String extension = name.substring(name.lastIndexOf(?.?) + 1); which is to say the extension is the portion of the file name string after but not including the last period character (dot). This effort faded out. [2] Apr. 2021 - Mar. 2022 A pull request was proposed and culminated in the proposal of the Path method String getExtension(String defaultExtension) where in the common case the extension is once again the portion of the file name string after the last dot. For degenerate cases the ?defaultExtension? parameter would be returned. This effort was superseded by [3]. [3] Mar. 2022 - Dec. 2022 This pull request specified the Path method String getExtension() which in the common case returned the portion of the file name string after the last dot, and in unusual cases either the empty string (terminal dot) or null (no dot). For a time this proposal used Optional but that was dropped as unwieldy. This PR was approved and integrated. [4] Dec. 2022 Due primarily to the undesirability of the possibility of a null return value and the lateness of the integration in the development cycle, the API added in [3] was backed out. [5] Dec. 22 A new issue was filed to track the resumption of eventual work on this topic. This issue suggested that the last dot be included in the extension, e.g., the extension of ?image.jpg? would be ?.jpg? rather than ?jpg? and that the value returned by getExtension would never be null. It also proposed a complementary method Path.removeExtension which, together with Path.getExtension, would form an invariant Path path = ...; assert path.equals(path.removeExtension() + path.getExtension()); which would obviate the need to handle a period character explicitly. [1] https://mail.openjdk.org/pipermail/nio-dev/2018-February/004716.html [2] https://github.com/openjdk/jdk/pull/2319 [3] https://github.com/openjdk/jdk/pull/8066 [4] https://github.com/openjdk/jdk/pull/11566 [5] https://bugs.openjdk.org/browse/JDK-8298318 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvernee at openjdk.org Tue Oct 10 21:04:24 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 10 Oct 2023 21:04:24 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v35] In-Reply-To: References: Message-ID: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: update copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/b4a7b7ab..35ca1921 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=34 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=33-34 Stats: 107 lines in 107 files changed: 0 ins; 0 del; 107 mod Patch: https://git.openjdk.org/jdk/pull/15103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103 PR: https://git.openjdk.org/jdk/pull/15103 From roger.riggs at oracle.com Tue Oct 10 21:31:35 2023 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 10 Oct 2023 17:31:35 -0400 Subject: [Request for Comments] File extension redux In-Reply-To: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com> References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com> Message-ID: Hi Brian, First the intuition and then the rationale. Intuition: the extension does not include the period '.' learned from years of working with existing systems, both shell and programming languages with file apis. Second: In trying to make Path.getExtension() handle all of the use cases possible, it makes some of them more difficult.? In particular, the cases for removing or replacing the extension are easier to do with a method for that purpose. It is easier to explain using a Path.removeExtension() method than to explain how to convert the path to a string and then remove some number of characters from the end and recreate the Path. Rationale: * Other Java libraries that provide path name utilities do not include the dot as part of the extension; (Guava and Apache Commons). A mismatch with them (and other common Java libraries) creates friction and room to make mistakes in conversions between different representations. * The no-dot representation works just fine except in the case of trailing dot, which is quite uncommon in practice. * The APIs provided should do what the programmer needs to do, not be APIs from which the programmer can create the API they need and still avoid an explosion of APIs for narrow use cases. * Extensions are used in many ways, from switch statements to keys in maps to simple if/then/else; some are hard coded and others are configured or loaded as plugins. The semantics should be simple and direct. For 1) and 3) I would say that both "foo" or "foo." have an empty ("") extension. Providing a removeExtension() or replaceExtension(String) method can embed the edge case handling and make the API easy to use without having to burden the Path.getExtension() method with a model that includes that complexity. Regards, Roger On 10/10/23 2:31 PM, Brian Burkhalter wrote: > I would like to resurrect this topic which has languished for quite a > while now. It was discussed for probably decades before my involvement > with it. A brief outline of its most recent history is included below. > The essence is that it would be good to add a > java.nio.file.Path.getExtension method, and possibly one or more > companion methods. General comments on the topic are welcome > regardless of whether the included chronology is reviewed. Things to > consider include: > > 1) whether a getExtension method ever returns null; > 2) whether a period character is included as the first character of > the returned extension; > 3) whether the extension of ?foo? (no dot) differs from that of ?foo.? > (terminal dot). > > Thanks, > > Brian > > --- snip --- TL;DR --- snip --- > > [1] Feb. 2018 > Path.hasExtension was initially proposed but dropped in favor of > Path.getExtension. This method was for the most common cases equivalent to > > Path path = ...; > String name = path.getFileName(); > String extension = name.substring(name.lastIndexOf(?.?) + 1); > > which is to say the extension is the portion of the file name string > after but not including the last period character (dot). This effort > faded out. > > [2] Apr. 2021 - Mar. 2022 > A pull request was proposed and culminated in the proposal of the Path > method > > String getExtension(String defaultExtension) > > where in the common case the extension is once again the portion of > the file name string after the last dot. For degenerate cases the > ?defaultExtension? parameter would be returned.? This effort was > superseded by [3]. > > [3] Mar. 2022 - Dec. 2022 > > This pull request specified the Path method > > String getExtension() > > which in the common case returned the portion of the file name string > after the last dot, and in unusual cases either the empty string > (terminal dot) or null (no dot). For a time this proposal used > Optional but that was dropped as unwieldy. This PR was approved and > integrated. > > [4] Dec. 2022 > > Due primarily to the undesirability of the possibility of a null > return value and the lateness of the integration in the development > cycle, the API added in [3] was backed out. > > [5] Dec. 22 > > A new issue was filed to track the resumption of eventual work on this > topic. This issue suggested that the last dot be included in the > extension, e.g., the extension of ?image.jpg? would be ?.jpg? rather > than ?jpg? and that the value returned by getExtension would never be > null. It also proposed a complementary method Path.removeExtension > which, together with Path.getExtension, would form an invariant > > Path path = ...; > assert path.equals(path.removeExtension() + path.getExtension()); > > which would obviate the need to handle a period character explicitly. > > [1] https://mail.openjdk.org/pipermail/nio-dev/2018-February/004716.html > [2] https://github.com/openjdk/jdk/pull/2319 > [3] https://github.com/openjdk/jdk/pull/8066 > [4] https://github.com/openjdk/jdk/pull/11566 > [5] https://bugs.openjdk.org/browse/JDK-8298318 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvernee at openjdk.org Tue Oct 10 23:17:17 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 10 Oct 2023 23:17:17 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v36] In-Reply-To: References: Message-ID: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: adjust misformatted copyright headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/35ca1921..5cf9e753 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=35 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=34-35 Stats: 66 lines in 4 files changed: 0 ins; 0 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/15103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103 PR: https://git.openjdk.org/jdk/pull/15103 From clanger at openjdk.org Wed Oct 11 05:48:39 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 11 Oct 2023 05:48:39 GMT Subject: RFR: 8317839: Exclude java/nio/channels/Channels/SocketChannelStreams.java on AIX Message-ID: The test java/nio/channels/Channels/SocketChannelStreams.java often times out on AIX and should be excluded. ------------- Commit messages: - JDK-8317839 Changes: https://git.openjdk.org/jdk/pull/16129/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16129&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317839 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16129/head:pull/16129 PR: https://git.openjdk.org/jdk/pull/16129 From alanb at openjdk.org Wed Oct 11 05:53:08 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 11 Oct 2023 05:53:08 GMT Subject: RFR: 8317839: Exclude java/nio/channels/Channels/SocketChannelStreams.java on AIX In-Reply-To: References: Message-ID: <2oZNEGggEa9MUCGK1zAye203ihTCLfQQUes-1-OaWzo=.82f52f09-9c00-4807-b6a9-24c7bc5d07b9@github.com> On Tue, 10 Oct 2023 21:45:46 GMT, Christoph Langer wrote: > The test java/nio/channels/Channels/SocketChannelStreams.java often times out on AIX and should be excluded. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16129#pullrequestreview-1669989720 From mbaesken at openjdk.org Wed Oct 11 06:44:11 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Oct 2023 06:44:11 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v8] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Tue, 10 Oct 2023 11:32:16 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove blank line Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1756936040 From mbaesken at openjdk.org Wed Oct 11 06:47:26 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Oct 2023 06:47:26 GMT Subject: Integrated: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) In-Reply-To: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Thu, 5 Oct 2023 14:33:14 GMT, Matthias Baesken wrote: > On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. > This leads sometimes to exceptions like > > MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] > > see https://bugs.openjdk.org/browse/JDK-8317307 > > It would be better to have a message explaining the reason instead of "no further information" . This pull request has now been integrated. Changeset: a9b41da9 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/a9b41da9df398ae7e2cf598b2779808d16504e14 Stats: 39 lines in 5 files changed: 5 ins; 8 del; 26 mod 8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) Reviewed-by: vtewari, alanb, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/16057 From clanger at openjdk.org Wed Oct 11 06:57:18 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 11 Oct 2023 06:57:18 GMT Subject: Integrated: 8317839: Exclude java/nio/channels/Channels/SocketChannelStreams.java on AIX In-Reply-To: References: Message-ID: On Tue, 10 Oct 2023 21:45:46 GMT, Christoph Langer wrote: > The test java/nio/channels/Channels/SocketChannelStreams.java often times out on AIX and should be excluded. This pull request has now been integrated. Changeset: ca96fd3b Author: Christoph Langer URL: https://git.openjdk.org/jdk/commit/ca96fd3b07958a7de6274bd945490bb9e79c2170 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8317839: Exclude java/nio/channels/Channels/SocketChannelStreams.java on AIX Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/16129 From mbaesken at openjdk.org Wed Oct 11 08:06:21 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Oct 2023 08:06:21 GMT Subject: RFR: JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win) [v8] In-Reply-To: References: <2ADL4b2iNAT7DiN_6GrjfXAE3kyUlPXnDXIhP_oFoNo=.91036cc1-6709-450b-90f1-88642968317c@github.com> Message-ID: On Tue, 10 Oct 2023 11:32:16 GMT, Matthias Baesken wrote: >> On Windows, we miss a handleSocketErrorWithMessage function that provides an additional message showing what went wrong in the Net.c coding. On Unix we have this function. >> This leads sometimes to exceptions like >> >> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] >> >> see https://bugs.openjdk.org/browse/JDK-8317307 >> >> It would be better to have a message explaining the reason instead of "no further information" . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove blank line created https://github.com/openjdk/jdk/pull/16057#pullrequestreview-1668536894 for the suggested NET_SocketAvailable removal/replacement . ------------- PR Comment: https://git.openjdk.org/jdk/pull/16057#issuecomment-1757072147 From mbaesken at openjdk.org Wed Oct 11 08:08:05 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Oct 2023 08:08:05 GMT Subject: RFR: JDK-8317866: replace NET_SocketAvailable Message-ID: When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced. ------------- Commit messages: - JDK-8317866 Changes: https://git.openjdk.org/jdk/pull/16139/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16139&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317866 Stats: 34 lines in 4 files changed: 4 ins; 27 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16139/head:pull/16139 PR: https://git.openjdk.org/jdk/pull/16139 From pminborg at openjdk.org Wed Oct 11 09:08:40 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 11 Oct 2023 09:08:40 GMT Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer Message-ID: This PR proposed to Add @sealedGraph to `ByteBuffer`. ------------- Commit messages: - Add @sealedGraph to ByteBuffer Changes: https://git.openjdk.org/jdk/pull/16142/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16142&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317886 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16142/head:pull/16142 PR: https://git.openjdk.org/jdk/pull/16142 From dfuchs at openjdk.org Wed Oct 11 10:45:10 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 11 Oct 2023 10:45:10 GMT Subject: RFR: JDK-8317866: replace NET_SocketAvailable In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken wrote: > When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced. This looks reasonable. Thanks for the cleanup! Let me run some test before approving. ------------- PR Review: https://git.openjdk.org/jdk/pull/16139#pullrequestreview-1670752677 From alanb at openjdk.org Wed Oct 11 11:11:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 11 Oct 2023 11:11:15 GMT Subject: RFR: JDK-8317866: replace NET_SocketAvailable In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken wrote: > When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16139#pullrequestreview-1670860910 From mbaesken at openjdk.org Wed Oct 11 13:42:28 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Oct 2023 13:42:28 GMT Subject: RFR: JDK-8038244: (fs) Check return value of malloc in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() Message-ID: There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory). ------------- Commit messages: - JDK-8038244 Changes: https://git.openjdk.org/jdk/pull/16151/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16151&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8038244 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16151.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16151/head:pull/16151 PR: https://git.openjdk.org/jdk/pull/16151 From rriggs at openjdk.org Wed Oct 11 14:02:19 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 11 Oct 2023 14:02:19 GMT Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 08:59:47 GMT, Per Minborg wrote: > This PR proposed to Add @sealedGraph to `ByteBuffer`. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16142#pullrequestreview-1671319653 From bpb at openjdk.org Wed Oct 11 15:21:11 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Oct 2023 15:21:11 GMT Subject: RFR: JDK-8038244: (fs) Check return value of malloc in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() In-Reply-To: References: Message-ID: <4ud5HEzi5w3K5OKQWxXzVnMPiVEafbbOBqw2j-wJHdM=.00ec7f5b-43de-4fd9-84d0-3e8afee7710c@github.com> On Wed, 11 Oct 2023 13:35:55 GMT, Matthias Baesken wrote: > There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory). Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16151#pullrequestreview-1671538361 From brian.burkhalter at oracle.com Wed Oct 11 15:54:44 2023 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 11 Oct 2023 15:54:44 +0000 Subject: [Request for Comments] File extension redux In-Reply-To: References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com> Message-ID: Hi Roger, Thanks for the detailed, prompt response. It appears that what I have been thinking is pretty much in line with what you wrote. Specifically I have been considering the following proposal: * In the common case, the extension is the sequence of characters after the last period character in the file name. * The extension does not include the period character. * An indeterminate extension is represented by the empty string ??; no nulls. * Three methods could be added to Path: * String getExtension() * Path removeExtension() * Path addExtension(String) * For a given Path p this invariant would be satisfied: * p.equals(p.removeExtension().addExtension(p.getExtension())) == true The foregoing approach would, I think, obviate the need to directly handle the period character. Thanks, Brian On Oct 10, 2023, at 2:31 PM, Roger Riggs > wrote: Hi Brian, First the intuition and then the rationale. Intuition: the extension does not include the period '.' learned from years of working with existing systems, both shell and programming languages with file apis. Second: In trying to make Path.getExtension() handle all of the use cases possible, it makes some of them more difficult. In particular, the cases for removing or replacing the extension are easier to do with a method for that purpose. It is easier to explain using a Path.removeExtension() method than to explain how to convert the path to a string and then remove some number of characters from the end and recreate the Path. Rationale: * Other Java libraries that provide path name utilities do not include the dot as part of the extension; (Guava and Apache Commons). A mismatch with them (and other common Java libraries) creates friction and room to make mistakes in conversions between different representations. * The no-dot representation works just fine except in the case of trailing dot, which is quite uncommon in practice. * The APIs provided should do what the programmer needs to do, not be APIs from which the programmer can create the API they need and still avoid an explosion of APIs for narrow use cases. * Extensions are used in many ways, from switch statements to keys in maps to simple if/then/else; some are hard coded and others are configured or loaded as plugins. The semantics should be simple and direct. For 1) and 3) I would say that both "foo" or "foo." have an empty ("") extension. Providing a removeExtension() or replaceExtension(String) method can embed the edge case handling and make the API easy to use without having to burden the Path.getExtension() method with a model that includes that complexity. Regards, Roger On 10/10/23 2:31 PM, Brian Burkhalter wrote: I would like to resurrect this topic which has languished for quite a while now. It was discussed for probably decades before my involvement with it. A brief outline of its most recent history is included below. The essence is that it would be good to add a java.nio.file.Path.getExtension method, and possibly one or more companion methods. General comments on the topic are welcome regardless of whether the included chronology is reviewed. Things to consider include: 1) whether a getExtension method ever returns null; 2) whether a period character is included as the first character of the returned extension; 3) whether the extension of ?foo? (no dot) differs from that of ?foo.? (terminal dot). Thanks, Brian --- snip --- TL;DR --- snip --- [1] Feb. 2018 Path.hasExtension was initially proposed but dropped in favor of Path.getExtension. This method was for the most common cases equivalent to Path path = ...; String name = path.getFileName(); String extension = name.substring(name.lastIndexOf(?.?) + 1); which is to say the extension is the portion of the file name string after but not including the last period character (dot). This effort faded out. [2] Apr. 2021 - Mar. 2022 A pull request was proposed and culminated in the proposal of the Path method String getExtension(String defaultExtension) where in the common case the extension is once again the portion of the file name string after the last dot. For degenerate cases the ?defaultExtension? parameter would be returned. This effort was superseded by [3]. [3] Mar. 2022 - Dec. 2022 This pull request specified the Path method String getExtension() which in the common case returned the portion of the file name string after the last dot, and in unusual cases either the empty string (terminal dot) or null (no dot). For a time this proposal used Optional but that was dropped as unwieldy. This PR was approved and integrated. [4] Dec. 2022 Due primarily to the undesirability of the possibility of a null return value and the lateness of the integration in the development cycle, the API added in [3] was backed out. [5] Dec. 22 A new issue was filed to track the resumption of eventual work on this topic. This issue suggested that the last dot be included in the extension, e.g., the extension of ?image.jpg? would be ?.jpg? rather than ?jpg? and that the value returned by getExtension would never be null. It also proposed a complementary method Path.removeExtension which, together with Path.getExtension, would form an invariant Path path = ...; assert path.equals(path.removeExtension() + path.getExtension()); which would obviate the need to handle a period character explicitly. [1] https://mail.openjdk.org/pipermail/nio-dev/2018-February/004716.html [2] https://github.com/openjdk/jdk/pull/2319 [3] https://github.com/openjdk/jdk/pull/8066 [4] https://github.com/openjdk/jdk/pull/11566 [5] https://bugs.openjdk.org/browse/JDK-8298318 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfuchs at openjdk.org Wed Oct 11 16:40:23 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 11 Oct 2023 16:40:23 GMT Subject: RFR: JDK-8317866: replace NET_SocketAvailable In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken wrote: > When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16139#pullrequestreview-1671817764 From iris at openjdk.org Wed Oct 11 16:40:24 2023 From: iris at openjdk.org (Iris Clark) Date: Wed, 11 Oct 2023 16:40:24 GMT Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 08:59:47 GMT, Per Minborg wrote: > This PR proposed to Add @sealedGraph to `ByteBuffer`. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16142#pullrequestreview-1671798420 From david.lloyd at redhat.com Wed Oct 11 16:50:33 2023 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 11 Oct 2023 11:50:33 -0500 Subject: [Request for Comments] File extension redux In-Reply-To: References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com> Message-ID: For the edge case where the file ends in, /or/ comprises, a solitary `.`, would `removeExtension()` remove the `.` and `addExtension("")` add it back, or would both methods leave the path unaffected (either one would satisfy the invariant)? Or some other behavior? On Wed, Oct 11, 2023 at 10:56?AM Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > Hi Roger, > > Thanks for the detailed, prompt response. It appears that what I have been > thinking is pretty much in line with what you wrote. Specifically I have > been considering the following proposal: > > > - In the common case, the extension is the sequence of characters > after the last period character in the file name. > - The extension does *not* include the period character. > - An indeterminate extension is represented by the empty string ??; no > nulls. > - Three methods could be added to Path: > - String getExtension() > - Path removeExtension() > - Path addExtension(String) > - For a given Path p this invariant would be satisfied: > - p.equals(p.removeExtension().addExtension(p.getExtension())) == > true > > > The foregoing approach would, I think, obviate the need to directly handle > the period character. > > Thanks, > > Brian > > On Oct 10, 2023, at 2:31 PM, Roger Riggs wrote: > > Hi Brian, > > First the intuition and then the rationale. > > Intuition: the extension does not include the period '.' learned from > years of working with existing systems, both shell and programming > languages with file apis. > > Second: In trying to make Path.getExtension() handle all of the use cases > possible, it makes some of them more difficult. In particular, the cases > for removing or replacing the extension are easier to do with a method for > that purpose. It is easier to explain using a Path.removeExtension() method > than to explain how to convert the path to a string and then remove some > number of characters from the end and recreate the Path. > > Rationale: > > - Other Java libraries that provide path name utilities do not include > the dot as part of the extension; (Guava and Apache Commons). A mismatch > with them (and other common Java libraries) creates friction and room to > make mistakes in conversions between different representations. > - The no-dot representation works just fine except in the case of > trailing dot, which is quite uncommon in practice. > - The APIs provided should do what the programmer needs to do, not be > APIs from which the programmer can create the API they need and still avoid > an explosion of APIs for narrow use cases. > - Extensions are used in many ways, from switch statements to keys in > maps to simple if/then/else; some are hard coded and others are configured > or loaded as plugins. The semantics should be simple and direct. > > For 1) and 3) I would say that both "foo" or "foo." have an empty ("") > extension. > Providing a removeExtension() or replaceExtension(String) method can embed > the edge case handling and make the API easy to use without having to > burden the Path.getExtension() method with a model that includes that > complexity. > > Regards, Roger > > > On 10/10/23 2:31 PM, Brian Burkhalter wrote: > > I would like to resurrect this topic which has languished for quite a > while now. It was discussed for probably decades before my involvement with > it. A brief outline of its most recent history is included below. The > essence is that it would be good to add a java.nio.file.Path.getExtension > method, and possibly one or more companion methods. General comments on the > topic are welcome regardless of whether the included chronology is > reviewed. Things to consider include: > > 1) whether a getExtension method ever returns null; > 2) whether a period character is included as the first character of the > returned extension; > 3) whether the extension of ?foo? (no dot) differs from that of ?foo.? > (terminal dot). > > Thanks, > > Brian > > --- snip --- TL;DR --- snip --- > > [1] Feb. 2018 > Path.hasExtension was initially proposed but dropped in favor of > Path.getExtension. This method was for the most common cases equivalent to > > Path path = ...; > String name = path.getFileName(); > String extension = name.substring(name.lastIndexOf(?.?) + 1); > > which is to say the extension is the portion of the file name string after > but not including the last period character (dot). This effort faded out. > > [2] Apr. 2021 - Mar. 2022 > A pull request was proposed and culminated in the proposal of the Path > method > > String getExtension(String defaultExtension) > > where in the common case the extension is once again the portion of the > file name string after the last dot. For degenerate cases the > ?defaultExtension? parameter would be returned. This effort was superseded > by [3]. > > [3] Mar. 2022 - Dec. 2022 > > This pull request specified the Path method > > String getExtension() > > which in the common case returned the portion of the file name string > after the last dot, and in unusual cases either the empty string (terminal > dot) or null (no dot). For a time this proposal used Optional but that was > dropped as unwieldy. This PR was approved and integrated. > > [4] Dec. 2022 > > Due primarily to the undesirability of the possibility of a null return > value and the lateness of the integration in the development cycle, the API > added in [3] was backed out. > > [5] Dec. 22 > > A new issue was filed to track the resumption of eventual work on this > topic. This issue suggested that the last dot be included in the extension, > e.g., the extension of ?image.jpg? would be ?.jpg? rather than ?jpg? and > that the value returned by getExtension would never be null. It also > proposed a complementary method Path.removeExtension which, together with > Path.getExtension, would form an invariant > > Path path = ...; > assert path.equals(path.removeExtension() + path.getExtension()); > > which would obviate the need to handle a period character explicitly. > > [1] https://mail.openjdk.org/pipermail/nio-dev/2018-February/004716.html > [2] https://github.com/openjdk/jdk/pull/2319 > [3] https://github.com/openjdk/jdk/pull/8066 > [4] https://github.com/openjdk/jdk/pull/11566 > [5] https://bugs.openjdk.org/browse/JDK-8298318 > > > > -- - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Oct 11 16:55:13 2023 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 11 Oct 2023 16:55:13 +0000 Subject: [Request for Comments] File extension redux In-Reply-To: References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com> Message-ID: I?ve not gone through 100% of the edge cases, but for this one I would think both add and remove would not affect ?.? or ?foo.?. Brian On Oct 11, 2023, at 9:50 AM, David Lloyd > wrote: For the edge case where the file ends in, /or/ comprises, a solitary `.`, would `removeExtension()` remove the `.` and `addExtension("")` add it back, or would both methods leave the path unaffected (either one would satisfy the invariant)? Or some other behavior? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vtewari at openjdk.org Wed Oct 11 17:38:26 2023 From: vtewari at openjdk.org (Vyom Tewari) Date: Wed, 11 Oct 2023 17:38:26 GMT Subject: RFR: JDK-8038244: (fs) Check return value of malloc in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 13:35:55 GMT, Matthias Baesken wrote: > There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory). Looks OK to me. ------------- Marked as reviewed by vtewari (Committer). PR Review: https://git.openjdk.org/jdk/pull/16151#pullrequestreview-1672038075 From rriggs at openjdk.org Wed Oct 11 18:16:04 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 11 Oct 2023 18:16:04 GMT Subject: RFR: JDK-8038244: (fs) Check return value of malloc in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() In-Reply-To: References: Message-ID: <-w1QkL31nOamtv83AzXtGv3kmKkDk-JhTJtv2ItcP9Q=.cb25ebf5-1432-4587-93a3-721dba04afcf@github.com> On Wed, 11 Oct 2023 13:35:55 GMT, Matthias Baesken wrote: > There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory). Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16151#pullrequestreview-1672174030 From roger.riggs at oracle.com Wed Oct 11 18:33:33 2023 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 11 Oct 2023 14:33:33 -0400 Subject: [Request for Comments] File extension redux In-Reply-To: References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com> Message-ID: <6c5da012-faf5-ffbb-51e2-5bae2cbcf8d3@oracle.com> Hi, Typically a leading "." (for the directories "." and "..") would not be considered the start of an extension.? (As was spec'd earlier). Both "/." and "/.." have an empty extension. I would suggest that `removeExtension()` would be more useful if it removed the final ".", if any. `addExtension("txt")` would be smart enough to handle both "abc." and "abc" resulting in "abc.txt". $.02, Roger On 10/11/23 12:55 PM, Brian Burkhalter wrote: > I?ve not gone through 100% of the edge cases, but for this one I would > think both add and remove would not affect ?.? or ?foo.?. > > Brian > >> On Oct 11, 2023, at 9:50 AM, David Lloyd wrote: >> >> For the edge case where the file ends in, /or/ comprises, a solitary >> `.`, would `removeExtension()` remove?the `.` and `addExtension("")` >> add it back, or would both methods leave the path unaffected (either >> one would satisfy the invariant)? Or some other behavior? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Oct 11 18:39:39 2023 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 11 Oct 2023 18:39:39 +0000 Subject: [Request for Comments] File extension redux In-Reply-To: <6c5da012-faf5-ffbb-51e2-5bae2cbcf8d3@oracle.com> References: <0B78F716-26F5-43B3-A911-A320ED9B2366@oracle.com> <6c5da012-faf5-ffbb-51e2-5bae2cbcf8d3@oracle.com> Message-ID: <781CA0B6-08FA-4421-83BB-F74ED9E38F2C@oracle.com> On Oct 11, 2023, at 11:33 AM, Roger Riggs > wrote: Typically a leading "." (for the directories "." and "..") would not be considered the start of an extension. (As was spec'd earlier). Both "/." and "/.." have an empty extension. Agreed. I would suggest that `removeExtension()` would be more useful if it removed the final ".", if any. `addExtension("txt")` would be smart enough to handle both "abc." and "abc" resulting in "abc.txt?. I think that would work. Aside from ?.?, ?..?, a leading ?.? to denote hidden files on UNIX, and various edge cases to be ignored for the moment, I look at the ?.? as a separator character somewhat analogous to File.separatorChar. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbaesken at openjdk.org Thu Oct 12 07:19:22 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 12 Oct 2023 07:19:22 GMT Subject: RFR: JDK-8038244: (fs) Check return value of malloc in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 13:35:55 GMT, Matthias Baesken wrote: > There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory). Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16151#issuecomment-1759063686 From mbaesken at openjdk.org Thu Oct 12 07:19:23 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 12 Oct 2023 07:19:23 GMT Subject: Integrated: JDK-8038244: (fs) Check return value of malloc in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 13:35:55 GMT, Matthias Baesken wrote: > There's a call to malloc() in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() where we don't check for a potentially NULL return value (i.e. out of memory). This pull request has now been integrated. Changeset: 6d6c9008 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/6d6c9008d5c87631771e194f475b14e178d16322 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8038244: (fs) Check return value of malloc in Java_sun_nio_fs_AixNativeDispatcher_getmntctl() Reviewed-by: bpb, vtewari, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/16151 From mbaesken at openjdk.org Thu Oct 12 07:25:23 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 12 Oct 2023 07:25:23 GMT Subject: RFR: JDK-8317866: replace NET_SocketAvailable In-Reply-To: References: Message-ID: <2LvAHcncM4Kz_4yLH4KfixikvW2sV087KwHsJnsSKCc=.cf19c19b-ffa0-4806-9d84-cb6f373edca5@github.com> On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken wrote: > When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced. Hi Daniel and Alan, thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16139#issuecomment-1759071633 From mbaesken at openjdk.org Thu Oct 12 07:25:25 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 12 Oct 2023 07:25:25 GMT Subject: Integrated: JDK-8317866: replace NET_SocketAvailable In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken wrote: > When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it became clear that NET_SocketAvailable should be replaced. This pull request has now been integrated. Changeset: 424de295 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/424de295a6ca19e9aacb7e1e1c9b5f955064cb65 Stats: 34 lines in 4 files changed: 4 ins; 27 del; 3 mod 8317866: replace NET_SocketAvailable Reviewed-by: dfuchs, alanb ------------- PR: https://git.openjdk.org/jdk/pull/16139 From mbaesken at openjdk.org Thu Oct 12 08:09:44 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 12 Oct 2023 08:09:44 GMT Subject: RFR: JDK-8317959: Check return values of malloc in native java.base coding Message-ID: There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted. ------------- Commit messages: - JDK-8317959 Changes: https://git.openjdk.org/jdk/pull/16160/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16160&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317959 Stats: 26 lines in 4 files changed: 24 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16160/head:pull/16160 PR: https://git.openjdk.org/jdk/pull/16160 From alanb at openjdk.org Thu Oct 12 13:02:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Oct 2023 13:02:55 GMT Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 08:59:47 GMT, Per Minborg wrote: > This PR proposed to Add @sealedGraph to `ByteBuffer`. Would it possible to include an image on how this looks? Asking because Buffer already has sealedGraph so shows the hierarchy. For ByteBuffer then presumably it will just show that MBB extends BB so I'm wondering if it's useful or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16142#issuecomment-1759462766 From alanb at openjdk.org Thu Oct 12 13:04:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Oct 2023 13:04:18 GMT Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix") incorrectly returns 'true' for FAT32 volume on macOS [v2] In-Reply-To: References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> Message-ID: <_ejoUp3sp4K0v5lAOJcfVT-zpBeIS23Ivhv0c3a8L-8=.ef3788d6-57d7-4450-b141-f3c56da43297@github.com> On Mon, 9 Oct 2023 19:00:02 GMT, Brian Burkhalter wrote: >> Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8317687: Return false for "unix" view of FAT Marked as reviewed by alanb (Reviewer). src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 106: > 104: // POSIX attributes not supported on FAT > 105: if (type == PosixFileAttributeView.class && > 106: entry().fstype().equals("msdos")) The check would be easier to read if it were on one line. BTW: Shouldn't this say "FAT32" rather than "FAT"? ------------- PR Review: https://git.openjdk.org/jdk/pull/16084#pullrequestreview-1674005323 PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1356729152 From alanb at openjdk.org Thu Oct 12 13:07:48 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Oct 2023 13:07:48 GMT Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket events In-Reply-To: References: Message-ID: On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin wrote: > Hi, > > The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. > > Testing: jdk/jdk/jfr > > Thanks > Erik Changes in this area only require one reviewer so it's okay to integrate if you want. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15908#issuecomment-1759495468 From pminborg at openjdk.org Thu Oct 12 13:54:33 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 12 Oct 2023 13:54:33 GMT Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 11:54:53 GMT, Alan Bateman wrote: > Would it possible to include an image on how this looks? Asking because Buffer already has sealedGraph so shows the hierarchy. For ByteBuffer then presumably it will just show that MBB extends BB so I'm wondering if it's useful or not. As you say, `Buffer` already has the tag, and because of that the JavaDoc of the class will include a graph: image However, the tag works on a per-class basis and is not transitive. So ByteBuffer will not have a graph even though it and its permitted subclass MBB is rendered for the `Buffer` class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16142#issuecomment-1759573618 From alanb at openjdk.org Thu Oct 12 13:54:33 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Oct 2023 13:54:33 GMT Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 13:03:53 GMT, Per Minborg wrote: > However, the tag works on a per-class basis and is not transitive. So ByteBuffer will not have a graph even though it and its permitted subclass MBB is rendered for the `Buffer` class. It works well in Buffer as there is a hierarchy to show. It seems a bit confusing to me to have it also show up in the ByteBuffer docs. Have I missed something or what is the reason for doing this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16142#issuecomment-1759603209 From dfuchs at openjdk.org Thu Oct 12 14:02:04 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 12 Oct 2023 14:02:04 GMT Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket events In-Reply-To: References: Message-ID: On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin wrote: > Hi, > > The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. > > Testing: jdk/jdk/jfr > > Thanks > Erik LGTM - I was expecting @tprinzing to review too, but yes you can integrate if you want. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15908#pullrequestreview-1674252334 From mbaesken at openjdk.org Thu Oct 12 14:16:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 12 Oct 2023 14:16:55 GMT Subject: RFR: JDK-8317959: Check return values of malloc in native java.base coding [v2] In-Reply-To: References: Message-ID: > There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: doabort in check method in case no memory can be allocated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16160/files - new: https://git.openjdk.org/jdk/pull/16160/files/24fbb465..109b13c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16160&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16160&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16160/head:pull/16160 PR: https://git.openjdk.org/jdk/pull/16160 From alanb at openjdk.org Thu Oct 12 14:16:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Oct 2023 14:16:57 GMT Subject: RFR: JDK-8317959: Check return values of malloc in native java.base coding [v2] In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 12:17:27 GMT, Matthias Baesken wrote: >> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > doabort in check method in case no memory can be allocated src/java.base/windows/native/libjli/cmdtoargs.c line 327: > 325: // "pgmname" rest of cmdline ie. pgmname + 2 double quotes + space + cmdline from windows > 326: char* cptr = (char*) malloc(strlen(argv[0]) + sizeof(char) * 3 + strlen(cmdline) + 1); > 327: if (cptr == NULL) return false; This doesn't look right, I think it has no choice but to print an error and doabort.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16160#discussion_r1356709874 From mbaesken at openjdk.org Thu Oct 12 14:16:57 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 12 Oct 2023 14:16:57 GMT Subject: RFR: JDK-8317959: Check return values of malloc in native java.base coding [v2] In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 12:00:19 GMT, Alan Bateman wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> doabort in check method in case no memory can be allocated > > src/java.base/windows/native/libjli/cmdtoargs.c line 327: > >> 325: // "pgmname" rest of cmdline ie. pgmname + 2 double quotes + space + cmdline from windows >> 326: char* cptr = (char*) malloc(strlen(argv[0]) + sizeof(char) * 3 + strlen(cmdline) + 1); >> 327: if (cptr == NULL) return false; > > This doesn't look right, I think it has no choice but to print an error and doabort.. Hi Alan, I adjusted this part of the coding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16160#discussion_r1356728099 From tprinzing at openjdk.org Thu Oct 12 14:47:38 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Thu, 12 Oct 2023 14:47:38 GMT Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket events In-Reply-To: References: Message-ID: On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin wrote: > Hi, > > The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. > > Testing: jdk/jdk/jfr > > Thanks > Erik I was planning to change the convenience function to take functions as arguments. With this change there is a bunch of duplicated code. I was planning to push the change for JDK-8310978 today, but I guess that will have to wait as it's impacted by this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15908#issuecomment-1759755174 From bpb at openjdk.org Thu Oct 12 15:17:36 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Oct 2023 15:17:36 GMT Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix") incorrectly returns 'true' for FAT32 volume on macOS [v2] In-Reply-To: <_ejoUp3sp4K0v5lAOJcfVT-zpBeIS23Ivhv0c3a8L-8=.ef3788d6-57d7-4450-b141-f3c56da43297@github.com> References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> <_ejoUp3sp4K0v5lAOJcfVT-zpBeIS23Ivhv0c3a8L-8=.ef3788d6-57d7-4450-b141-f3c56da43297@github.com> Message-ID: On Thu, 12 Oct 2023 12:18:21 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8317687: Return false for "unix" view of FAT > > src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 106: > >> 104: // POSIX attributes not supported on FAT >> 105: if (type == PosixFileAttributeView.class && >> 106: entry().fstype().equals("msdos")) > > The check would be easier to read if it were on one line. > > BTW: Shouldn't this say "FAT32" rather than "FAT"? Yes. Same story in `LinuxFileStore`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1356982609 From bpb at openjdk.org Thu Oct 12 15:38:40 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Oct 2023 15:38:40 GMT Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix") incorrectly returns 'true' for FAT32 volume on macOS [v3] In-Reply-To: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> Message-ID: <-v-gPQBDAixxoIr7bYBvzwprj7I_FFzQKf47Onu-swI=.c4551bfb-ea19-478e-995c-a08772eca289@github.com> > Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8317687: /FAT/FAT32/ in comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16084/files - new: https://git.openjdk.org/jdk/pull/16084/files/0cc942c2..853caa1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16084&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16084&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16084/head:pull/16084 PR: https://git.openjdk.org/jdk/pull/16084 From bpb at openjdk.org Thu Oct 12 15:38:42 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Oct 2023 15:38:42 GMT Subject: RFR: 8317687: (fs) FileStore.supportsFileAttributeView("posix") incorrectly returns 'true' for FAT32 volume on macOS [v2] In-Reply-To: References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> <_ejoUp3sp4K0v5lAOJcfVT-zpBeIS23Ivhv0c3a8L-8=.ef3788d6-57d7-4450-b141-f3c56da43297@github.com> Message-ID: On Thu, 12 Oct 2023 15:15:05 GMT, Brian Burkhalter wrote: >> src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java line 106: >> >>> 104: // POSIX attributes not supported on FAT >>> 105: if (type == PosixFileAttributeView.class && >>> 106: entry().fstype().equals("msdos")) >> >> The check would be easier to read if it were on one line. >> >> BTW: Shouldn't this say "FAT32" rather than "FAT"? > > Yes. Same story in `LinuxFileStore`. Comments so change in 853caa1b4b3360c5026b0c6df11c61825234a302. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16084#discussion_r1357012113 From egahlin at openjdk.org Thu Oct 12 15:51:28 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 12 Oct 2023 15:51:28 GMT Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket events In-Reply-To: References: Message-ID: <5CpsTt095Fp76yWPbqfYuiWBqB5HoJPyTIhkNifUBP8=.73812635-fefd-4fd3-8366-484bb9e0c0c6@github.com> On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin wrote: > Hi, > > The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. > > Testing: jdk/jdk/jfr > > Thanks > Erik > I was planning to change the convenience function to take functions as arguments. With this change there is a bunch of duplicated code. > > I was planning to push the change for JDK-8310978 today, but I guess that will have to wait as it's impacted by this. > I was planning to change the convenience function to take functions as arguments. With this change there is a bunch of duplicated code. > > I was planning to push the change for JDK-8310978 today, but I guess that will have to wait as it's impacted by this. If it's a lambda, it could be problematic. I have another change coming up, which also motivated this PR. It's still in draft, need to decide on the syntax, but it adds an annotation that can filter out stack frames, for example the emit() method. A lambda wouldn't get a proper method name. https://github.com/openjdk/jdk/pull/15867 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15908#issuecomment-1759888327 From alanb at openjdk.org Thu Oct 12 16:24:12 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Oct 2023 16:24:12 GMT Subject: RFR: JDK-8317959: Check return values of malloc in native java.base coding [v2] In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 14:16:55 GMT, Matthias Baesken wrote: >> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > doabort in check method in case no memory can be allocated Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16160#pullrequestreview-1674603470 From bpb at openjdk.org Thu Oct 12 16:49:15 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Oct 2023 16:49:15 GMT Subject: RFR: JDK-8317959: Check return values of malloc in native java.base coding [v2] In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 14:16:55 GMT, Matthias Baesken wrote: >> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > doabort in check method in case no memory can be allocated Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16160#pullrequestreview-1674660076 From bpb at openjdk.org Thu Oct 12 19:21:20 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Oct 2023 19:21:20 GMT Subject: RFR: 8312527: (api) Re-examine use of sun.nio.ch.Invoker.myGroupAndInvokeCount Message-ID: Initialize private static local variable `myGroupAndInvokeCount` to a `ThreadLocal` instead of to an anonymous class effectively identical to `ThreadLocal`. ------------- Commit messages: - 8312527: (api) Re-examine use of sun.nio.ch.Invoker.myGroupAndInvokeCount Changes: https://git.openjdk.org/jdk/pull/16170/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16170&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312527 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16170/head:pull/16170 PR: https://git.openjdk.org/jdk/pull/16170 From bpb at openjdk.org Thu Oct 12 19:21:21 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Oct 2023 19:21:21 GMT Subject: RFR: 8312527: (api) Re-examine use of sun.nio.ch.Invoker.myGroupAndInvokeCount In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 19:13:43 GMT, Brian Burkhalter wrote: > Initialize private static local variable `myGroupAndInvokeCount` to a `ThreadLocal` instead of to an anonymous class effectively identical to `ThreadLocal`. The anonymous class overrides `initialValue()` identically to how it is defined in `ThreadLocal` itself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16170#issuecomment-1760229250 From jvernee at openjdk.org Thu Oct 12 19:53:54 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 12 Oct 2023 19:53:54 GMT Subject: Integrated: 8312522: Implementation of Foreign Function & Memory API In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee wrote: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... This pull request has now been integrated. Changeset: 32ac72c3 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/32ac72c3d35138f5253e4defc948304ac3ea1b53 Stats: 4468 lines in 263 files changed: 2211 ins; 1196 del; 1061 mod 8312522: Implementation of Foreign Function & Memory API Co-authored-by: Maurizio Cimadamore Co-authored-by: Jorn Vernee Co-authored-by: Per Minborg Reviewed-by: dholmes, psandoz, mcimadamore, alanb ------------- PR: https://git.openjdk.org/jdk/pull/15103 From duke at openjdk.org Fri Oct 13 03:30:49 2023 From: duke at openjdk.org (xpbob) Date: Fri, 13 Oct 2023 03:30:49 GMT Subject: RFR: 8318058: Notify the jvm when the direct memory is oom Message-ID: Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits: 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError. 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod ------------- Commit messages: - 8318058: Notify the jvm when the direct memory is oom Changes: https://git.openjdk.org/jdk/pull/16176/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16176&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318058 Stats: 92 lines in 4 files changed: 87 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16176.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16176/head:pull/16176 PR: https://git.openjdk.org/jdk/pull/16176 From stuefe at openjdk.org Fri Oct 13 05:29:14 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 13 Oct 2023 05:29:14 GMT Subject: RFR: 8318058: Notify the jvm when the direct memory is oom In-Reply-To: References: Message-ID: On Fri, 13 Oct 2023 03:23:04 GMT, xpbob wrote: > Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits: > 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError. > 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod Undoubtedly useful, but there have been many discussions in the past about what does and does not constitute an OOM error, and IIRC, the stance of Oracle devs was "only if it is in java heap". Hence the missing OOM error when we cannot create threads, for instance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16176#issuecomment-1760881555 From alanb at openjdk.org Fri Oct 13 06:13:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 13 Oct 2023 06:13:21 GMT Subject: RFR: 8318058: Notify the jvm when the direct memory is oom In-Reply-To: References: Message-ID: On Fri, 13 Oct 2023 03:23:04 GMT, xpbob wrote: > Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits: > 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError. > 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod JDK-8294052 has some of the previous discussion on this issue. See also this thread where Man, Thomas, David and I discussed the topic: https://mail.openjdk.org/pipermail/nio-dev/2022-September/012119.html There were previous threads on the same topic, I can't find the links right now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16176#issuecomment-1760950115 From alanb at openjdk.org Fri Oct 13 06:25:20 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 13 Oct 2023 06:25:20 GMT Subject: RFR: 8312527: (ch) Re-examine use of sun.nio.ch.Invoker.myGroupAndInvokeCount In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 19:13:43 GMT, Brian Burkhalter wrote: > Initialize private static local variable `myGroupAndInvokeCount` to a `ThreadLocal` instead of to an anonymous class effectively identical to `ThreadLocal`. No need to override initialValue so I think this cleanup looks okay, ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16170#pullrequestreview-1675792412 From mbaesken at openjdk.org Fri Oct 13 06:53:34 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 13 Oct 2023 06:53:34 GMT Subject: RFR: JDK-8317959: Check return values of malloc in native java.base coding [v2] In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 14:16:55 GMT, Matthias Baesken wrote: >> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > doabort in check method in case no memory can be allocated Hi Alan and Brian, thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16160#issuecomment-1760994212 From mbaesken at openjdk.org Fri Oct 13 06:53:35 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 13 Oct 2023 06:53:35 GMT Subject: Integrated: JDK-8317959: Check return values of malloc in native java.base coding In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 08:00:30 GMT, Matthias Baesken wrote: > There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted. This pull request has now been integrated. Changeset: ff0b397e Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/ff0b397e135665fbc763bc4042b95c17f6c5367a Stats: 29 lines in 4 files changed: 27 ins; 0 del; 2 mod 8317959: Check return values of malloc in native java.base coding Reviewed-by: alanb, bpb ------------- PR: https://git.openjdk.org/jdk/pull/16160 From sgehwolf at openjdk.org Fri Oct 13 09:06:20 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 13 Oct 2023 09:06:20 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v14] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: - Drop @enablePreview in CreationTime test - Merge branch 'master' - Move trace message after platform specific blocks - Drop word 'Debug:' in CreationTime test code - Keep wrapper function signature compatible to statx - Refactor test so as to use Linker from JEP 454. @enablePreview still needed as of yet. This can go once JDK-8312522 integrates. - Add missing returns when statx is available - Use custom but compatible statx struct always - Link libCreationTimeHelper with -ldl - Merge branch 'master' into JDK-8316304-statx-create-time-new - ... and 10 more: https://git.openjdk.org/jdk/compare/80229be5...9fcdd965 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/cbb24e38..9fcdd965 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=12-13 Stats: 20110 lines in 677 files changed: 10264 ins; 4891 del; 4955 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From sgehwolf at openjdk.org Fri Oct 13 09:06:22 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 13 Oct 2023 09:06:22 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v13] In-Reply-To: References: Message-ID: <1xQOfkZnHpGNwWmy1JjmKlnLle_kSB0fT6vnZVBlSQA=.989f8208-69d4-4d9a-94c7-bdf7a06e69be@github.com> On Tue, 10 Oct 2023 08:44:49 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Move trace message after platform specific blocks https://github.com/openjdk/jdk/pull/15103 has been integrated now. I've merged master and removed `@enablePreview` from the test. No other changes have been done. I'm going to do a final round of testing and will probably integrate next week Monday. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1761167856 From sgehwolf at openjdk.org Fri Oct 13 14:50:44 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 13 Oct 2023 14:50:44 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v15] In-Reply-To: References: Message-ID: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Fix Linux Alpine build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15792/files - new: https://git.openjdk.org/jdk/pull/15792/files/9fcdd965..71ab818a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15792&range=13-14 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792 PR: https://git.openjdk.org/jdk/pull/15792 From sgehwolf at openjdk.org Fri Oct 13 14:51:10 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 13 Oct 2023 14:51:10 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v15] In-Reply-To: References: Message-ID: <4F4lcuo_OVfTSCYouosLi1K6YUvGs7DWxda3MYuefDs=.54fede75-f357-4efe-b4f1-ffbca93a5062@github.com> On Fri, 13 Oct 2023 14:50:44 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Fix Linux Alpine build src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 87: > 85: typedef unsigned short __uint16_t; > 86: typedef unsigned long int __uint64_t; > 87: #endif Not sure what changed on the lastest merge from master, but I was getting compile failures on Apine without this. It's a no-op for glibc. @AlanBateman @bplb Still ok? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1358366992 From alanb at openjdk.org Fri Oct 13 14:55:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 13 Oct 2023 14:55:07 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v15] In-Reply-To: <4F4lcuo_OVfTSCYouosLi1K6YUvGs7DWxda3MYuefDs=.54fede75-f357-4efe-b4f1-ffbca93a5062@github.com> References: <4F4lcuo_OVfTSCYouosLi1K6YUvGs7DWxda3MYuefDs=.54fede75-f357-4efe-b4f1-ffbca93a5062@github.com> Message-ID: On Fri, 13 Oct 2023 14:48:08 GMT, Severin Gehwolf wrote: > Not sure what changed on the lastest merge from master, but I was getting compile failures on Apine without this. It's a no-op for glibc. @AlanBateman @bplb Still ok? Yes, I don't have any other comments and I see you've dropped the enablePreview. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1358372178 From mcimadamore at openjdk.org Fri Oct 13 15:50:12 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 13 Oct 2023 15:50:12 GMT Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching NativeMemorySegmentImpl Message-ID: This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses. This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`). Doing so addresses a possible deadlock condition when using multiple threads. ------------- Commit messages: - Add test - Add copyright - Initial push Changes: https://git.openjdk.org/jdk/pull/16187/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16187&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317514 Stats: 484 lines in 12 files changed: 313 ins; 147 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/16187.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16187/head:pull/16187 PR: https://git.openjdk.org/jdk/pull/16187 From bpb at openjdk.org Fri Oct 13 16:20:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Oct 2023 16:20:53 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v15] In-Reply-To: References: <4F4lcuo_OVfTSCYouosLi1K6YUvGs7DWxda3MYuefDs=.54fede75-f357-4efe-b4f1-ffbca93a5062@github.com> Message-ID: On Fri, 13 Oct 2023 14:52:10 GMT, Alan Bateman wrote: >> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 87: >> >>> 85: typedef unsigned short __uint16_t; >>> 86: typedef unsigned long int __uint64_t; >>> 87: #endif >> >> Not sure what changed on the lastest merge from master, but I was getting compile failures on Apine without this. It's a no-op for glibc. @AlanBateman @bplb Still ok? > >> Not sure what changed on the lastest merge from master, but I was getting compile failures on Apine without this. It's a no-op for glibc. @AlanBateman @bplb Still ok? > > Yes, I don't have any other comments and I see you've dropped the enablePreview. Likewise. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1358477573 From bpb at openjdk.org Fri Oct 13 16:34:34 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Oct 2023 16:34:34 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v15] In-Reply-To: References: Message-ID: On Fri, 13 Oct 2023 14:50:44 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Fix Linux Alpine build Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1676858578 From jvernee at openjdk.org Fri Oct 13 17:10:14 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 13 Oct 2023 17:10:14 GMT Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching NativeMemorySegmentImpl In-Reply-To: References: Message-ID: On Fri, 13 Oct 2023 15:37:00 GMT, Maurizio Cimadamore wrote: > This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses. > This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`). > Doing so addresses a possible deadlock condition when using multiple threads. Marked as reviewed by jvernee (Reviewer). src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1289: > 1287: * A zero-length native segment modelling the {@code NULL} address. > 1288: */ > 1289: MemorySegment NULL = MemorySegment.ofAddress(0L); The old no-arg constructor can now be removed from NativeMemroySegmentImpl as well I believe. ------------- PR Review: https://git.openjdk.org/jdk/pull/16187#pullrequestreview-1676911705 PR Review Comment: https://git.openjdk.org/jdk/pull/16187#discussion_r1358523909 From mcimadamore at openjdk.org Fri Oct 13 17:31:15 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 13 Oct 2023 17:31:15 GMT Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching NativeMemorySegmentImpl [v2] In-Reply-To: References: Message-ID: > This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses. > This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`). > Doing so addresses a possible deadlock condition when using multiple threads. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16187/files - new: https://git.openjdk.org/jdk/pull/16187/files/2aad11cf..b9ad352b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16187&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16187&range=00-01 Stats: 12 lines in 2 files changed: 0 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16187.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16187/head:pull/16187 PR: https://git.openjdk.org/jdk/pull/16187 From jvernee at openjdk.org Fri Oct 13 17:31:16 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 13 Oct 2023 17:31:16 GMT Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching NativeMemorySegmentImpl [v2] In-Reply-To: References: Message-ID: <77pUHxjLJRpzN6PqTTlTW7t6wXKtSSFKGpXVVweEeao=.ac315f09-33be-4f43-9169-2599f6c58b41@github.com> On Fri, 13 Oct 2023 17:25:03 GMT, Maurizio Cimadamore wrote: >> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses. >> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`). >> Doing so addresses a possible deadlock condition when using multiple threads. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16187#pullrequestreview-1676985669 From pminborg at openjdk.org Fri Oct 13 17:48:09 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 13 Oct 2023 17:48:09 GMT Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching NativeMemorySegmentImpl [v2] In-Reply-To: References: Message-ID: On Fri, 13 Oct 2023 17:31:15 GMT, Maurizio Cimadamore wrote: >> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses. >> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`). >> Doing so addresses a possible deadlock condition when using multiple threads. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 49: > 47: */ > 48: public class SegmentFactories { > 49: We could make this a proper utility class by declaring the class final and having a private constructor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16187#discussion_r1358610000 From mcimadamore at openjdk.org Fri Oct 13 21:30:13 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 13 Oct 2023 21:30:13 GMT Subject: Integrated: 8317514: Ensure MemorySegment is initialized before touching NativeMemorySegmentImpl In-Reply-To: References: Message-ID: On Fri, 13 Oct 2023 15:37:00 GMT, Maurizio Cimadamore wrote: > This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses. > This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`). > Doing so addresses a possible deadlock condition when using multiple threads. This pull request has now been integrated. Changeset: 7cb2e6d6 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk/commit/7cb2e6d65b517b638a584149560a2ff9cc56c3b6 Stats: 496 lines in 12 files changed: 313 ins; 158 del; 25 mod 8317514: Ensure MemorySegment is initialized before touching NativeMemorySegmentImpl Co-authored-by: Jorn Vernee Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/16187 From mli at openjdk.org Sat Oct 14 18:20:54 2023 From: mli at openjdk.org (Hamlin Li) Date: Sat, 14 Oct 2023 18:20:54 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v15] In-Reply-To: References: Message-ID: On Fri, 13 Oct 2023 14:50:44 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Fix Linux Alpine build LGTM. ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15792#pullrequestreview-1678309912 From duke at openjdk.org Mon Oct 16 02:15:32 2023 From: duke at openjdk.org (xpbob) Date: Mon, 16 Oct 2023 02:15:32 GMT Subject: Withdrawn: 8318058: Notify the jvm when the direct memory is oom In-Reply-To: References: Message-ID: <0FMEIyZwzX0DoJNG8hnJpN0ey6Ox_SjPLK0gJ1COJ3A=.21bbcd0a-ded3-4a66-b13e-c190f094b3ef@github.com> On Fri, 13 Oct 2023 03:23:04 GMT, xpbob wrote: > Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits: > 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError. > 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/16176 From duke at openjdk.org Mon Oct 16 03:22:04 2023 From: duke at openjdk.org (xpbob) Date: Mon, 16 Oct 2023 03:22:04 GMT Subject: RFR: 8318058: Notify the jvm when the direct memory is oom In-Reply-To: References: Message-ID: On Fri, 13 Oct 2023 05:26:37 GMT, Thomas Stuefe wrote: >> Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits: >> 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError. >> 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod > > Undoubtedly useful, but there have been many discussions in the past about what does and does not constitute an OOM error, and IIRC, the stance of Oracle devs was "only if it is in java heap". Hence the missing OOM error when we cannot create threads, for instance. @tstuefe @AlanBateman Thanks for for sharing this information, We look forward to other solutions to this problem in the future ------------- PR Comment: https://git.openjdk.org/jdk/pull/16176#issuecomment-1763663559 From sgehwolf at openjdk.org Mon Oct 16 07:27:02 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 16 Oct 2023 07:27:02 GMT Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux [v15] In-Reply-To: References: Message-ID: On Fri, 13 Oct 2023 14:50:44 GMT, Severin Gehwolf wrote: >> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. >> >> Testing: >> - [x] GHA (MacOS X failure seems unrelated) >> - [x] `java.nio` tests. >> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Fix Linux Alpine build GHA's x86 (32bit) Linux tier1 test failure seems unrelated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1763874402 From sgehwolf at openjdk.org Mon Oct 16 07:44:17 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 16 Oct 2023 07:44:17 GMT Subject: Integrated: 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux In-Reply-To: References: Message-ID: On Mon, 18 Sep 2023 17:05:11 GMT, Severin Gehwolf wrote: > Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call. > > Testing: > - [x] GHA (MacOS X failure seems unrelated) > - [x] `java.nio` tests. > - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch. > > Thoughts? This pull request has now been integrated. Changeset: 0275efac Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/0275efac882d263f85a723828a95d621f8dadbfb Stats: 245 lines in 3 files changed: 229 ins; 0 del; 16 mod 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux Reviewed-by: stuefe, alanb, bpb, mli ------------- PR: https://git.openjdk.org/jdk/pull/15792 From jpai at openjdk.org Mon Oct 16 10:31:03 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 16 Oct 2023 10:31:03 GMT Subject: RFR: 8312527: (ch) Re-examine use of sun.nio.ch.Invoker.myGroupAndInvokeCount In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 19:13:43 GMT, Brian Burkhalter wrote: > Initialize private static local variable `myGroupAndInvokeCount` to a `ThreadLocal` instead of to an anonymous class effectively identical to `ThreadLocal`. The change looks fine to me ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16170#pullrequestreview-1679600411 From bpb at openjdk.org Mon Oct 16 14:52:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 16 Oct 2023 14:52:25 GMT Subject: Integrated: 8317687: (fs) FileStore.supportsFileAttributeView("posix") incorrectly returns 'true' for FAT32 volume on macOS In-Reply-To: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> References: <3mMYfKMioEX8zl8hpRm1mJ5kDDV3yFqSf2hf8S74x0Q=.67c85d54-3aee-4641-a3d4-04c357d02148@github.com> Message-ID: On Fri, 6 Oct 2023 21:39:32 GMT, Brian Burkhalter wrote: > Change `BsdFileStore.supportsFileAttributeView` to return false for POSIX attributes when the associated volume file system type is FAT32. This pull request has now been integrated. Changeset: 1a7fd5d4 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/1a7fd5d41901249f8e1e6f0aa1f2a3c9f265659d Stats: 36 lines in 3 files changed: 30 ins; 1 del; 5 mod 8317687: (fs) FileStore.supportsFileAttributeView("posix") incorrectly returns 'true' for FAT32 volume on macOS Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/16084 From bpb at openjdk.org Mon Oct 16 14:56:00 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 16 Oct 2023 14:56:00 GMT Subject: Integrated: 8312527: (ch) Re-examine use of sun.nio.ch.Invoker.myGroupAndInvokeCount In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 19:13:43 GMT, Brian Burkhalter wrote: > Initialize private static local variable `myGroupAndInvokeCount` to a `ThreadLocal` instead of to an anonymous class effectively identical to `ThreadLocal`. This pull request has now been integrated. Changeset: 0d091681 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/0d091681c2e440d05dc913131fbc2bdf4f15a31b Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod 8312527: (ch) Re-examine use of sun.nio.ch.Invoker.myGroupAndInvokeCount Reviewed-by: alanb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/16170 From bpb at openjdk.org Mon Oct 16 21:25:52 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 16 Oct 2023 21:25:52 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data Message-ID: Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. ------------- Commit messages: - 8306308: (ch) Writer created by Channels::newWriter may lose data Changes: https://git.openjdk.org/jdk/pull/16207/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306308 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16207/head:pull/16207 PR: https://git.openjdk.org/jdk/pull/16207 From bpb at openjdk.org Mon Oct 16 21:25:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 16 Oct 2023 21:25:53 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data In-Reply-To: References: Message-ID: On Mon, 16 Oct 2023 21:20:17 GMT, Brian Burkhalter wrote: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. I am not entirely certain that this change is exactly what @djelinski intended in his [comment](https://bugs.openjdk.org/browse/JDK-8306308?focusedCommentId=14575246&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14575246) on the issue. No tests are included pending comments on whether this is the right approach. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1765298062 From duke at openjdk.org Mon Oct 16 22:33:26 2023 From: duke at openjdk.org (Shaojin Wen) Date: Mon, 16 Oct 2023 22:33:26 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException Message-ID: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. ------------- Commit messages: - Make the NoRepl methods throw IllegalArgument Changes: https://git.openjdk.org/jdk/pull/16209/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318200 Stats: 93 lines in 8 files changed: 10 ins; 58 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/16209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209 PR: https://git.openjdk.org/jdk/pull/16209 From liach at openjdk.org Tue Oct 17 03:12:21 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 17 Oct 2023 03:12:21 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Mon, 16 Oct 2023 22:27:34 GMT, Shaojin Wen wrote: > When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed. src/java.base/share/classes/java/lang/String.java line 932: > 930: > 931: private static byte[] getBytesNoRepl1(String s, Charset cs) { > 932: return getBytesNoRepl1(s, cs); This method should probably be removed. This current implementation is an infinite recursion. src/java.base/share/classes/java/util/zip/ZipCoder.java line 319: > 317: } > 318: } catch (IllegalArgumentException e) { > 319: return Comparison.NO_MATCH; Should check if the cause is `CharacterCodingException` ------------- Changes requested by liach (Author). PR Review: https://git.openjdk.org/jdk/pull/16209#pullrequestreview-1681283802 PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361455389 PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361455717 From duke at openjdk.org Tue Oct 17 03:22:56 2023 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 17 Oct 2023 03:22:56 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v2] In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: > When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: fix from @liach 's review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16209/files - new: https://git.openjdk.org/jdk/pull/16209/files/aa76c505..d2063b08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=00-01 Stats: 9 lines in 2 files changed: 4 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209 PR: https://git.openjdk.org/jdk/pull/16209 From alanb at openjdk.org Tue Oct 17 06:00:19 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 17 Oct 2023 06:00:19 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data In-Reply-To: References: Message-ID: On Mon, 16 Oct 2023 21:20:17 GMT, Brian Burkhalter wrote: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. It's a simple approach but I think you'll create to some some benchmarks to demonstrate that the channel handling in StreamEncoder can be removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1765718960 From djelinski at openjdk.org Tue Oct 17 06:41:24 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 17 Oct 2023 06:41:24 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data In-Reply-To: References: Message-ID: On Mon, 16 Oct 2023 21:20:17 GMT, Brian Burkhalter wrote: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. Yes, that's what I had in mind. Note that this was the only place where `StreamEncoder.forEncoder` was used, which in turn was the only place where `StreamEncoder(WritableByteChannel ch, CharsetEncoder enc, int mbc)` was used, which in turn was the only place where `StreamEncoder#ch` was set, so this PR has potential to make the code much simpler. src/java.base/share/classes/java/nio/channels/Channels.java line 544: > 542: { > 543: Objects.requireNonNull(ch, "ch"); > 544: return StreamEncoder.forEncoder(ch, enc.reset(), minBufferCap); You could avoid one level of indirection by using `StreamEncoder.forOutputStreamWriter` instead of `new OutputStreamWriter` here. `OutputStreamWriter` is a pass-through wrapper for `StreamEncoder.forOutputStreamWriter` (except for [JDK-6856817](https://bugs.openjdk.org/browse/JDK-6856817) / dc93a924ee4d3b53f0271af577148f8a53eedb57, but that's another story) ------------- PR Review: https://git.openjdk.org/jdk/pull/16207#pullrequestreview-1681459462 PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1361569579 From redestad at openjdk.org Tue Oct 17 09:34:22 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 17 Oct 2023 09:34:22 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v2] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Tue, 17 Oct 2023 03:09:09 GMT, Chen Liang wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> fix from @liach 's review > > The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed. I agree with @liach that `Files.readString / writeString` should continue to throw `CCE`, not `IAE`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766035016 From alanb at openjdk.org Tue Oct 17 10:36:14 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 17 Oct 2023 10:36:14 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v2] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Tue, 17 Oct 2023 03:09:09 GMT, Chen Liang wrote: > The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed. Right, these APIs are specified to throw an IOException "If an I/O error occurs reading from the file or a malformed or unmappable byte sequence is read". Changing this to throw an unexpected IAE would be a breaking change. So good to spot this. Need to make sure that tier2 tests are run with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766104613 From egahlin at openjdk.org Tue Oct 17 10:39:34 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 17 Oct 2023 10:39:34 GMT Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket events [v2] In-Reply-To: References: Message-ID: <8NDoeo0_6Lajo0lBFyDRhy4EO0RoxYbnt7fhOK3ZcGk=.929f4ddb-b828-4101-88da-5ed9faf37627@github.com> > Hi, > > The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. > > Testing: jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Update microbenchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15908/files - new: https://git.openjdk.org/jdk/pull/15908/files/3b398bc4..185f6bfa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15908&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15908&range=00-01 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15908.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15908/head:pull/15908 PR: https://git.openjdk.org/jdk/pull/15908 From duke at openjdk.org Tue Oct 17 10:42:59 2023 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 17 Oct 2023 10:42:59 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v3] In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com> > When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Files.readString/writeString throws CCE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16209/files - new: https://git.openjdk.org/jdk/pull/16209/files/d2063b08..a93be313 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=01-02 Stats: 22 lines in 3 files changed: 16 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209 PR: https://git.openjdk.org/jdk/pull/16209 From redestad at openjdk.org Tue Oct 17 10:45:22 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 17 Oct 2023 10:45:22 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v3] In-Reply-To: <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com> References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com> Message-ID: On Tue, 17 Oct 2023 10:42:59 GMT, Shaojin Wen wrote: >> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Files.readString/writeString throws CCE test/jdk/java/lang/String/NoReplTest.java line 62: > 60: .withUpperCase() > 61: .formatHex(read.getBytes(UTF_16))); > 62: } catch (CharacterCodingException cce) { Shouldn't these test changes be completely reverted now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361904067 From duke at openjdk.org Tue Oct 17 11:11:52 2023 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 17 Oct 2023 11:11:52 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v4] In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: > When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: revert NoReplTest, from @cl4es 's review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16209/files - new: https://git.openjdk.org/jdk/pull/16209/files/a93be313..cc3bc9ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=02-03 Stats: 13 lines in 1 file changed: 0 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209 PR: https://git.openjdk.org/jdk/pull/16209 From alanb at openjdk.org Tue Oct 17 11:15:51 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 17 Oct 2023 11:15:51 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v4] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen wrote: >> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > revert NoReplTest, from @cl4es 's review src/java.base/share/classes/java/nio/file/Files.java line 3361: > 3359: throw cause; > 3360: } > 3361: throw e; This is wrong, if IAE is thrown for any other reason than CharacterCodingException then it means the JDK is broken. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361937982 From alanb at openjdk.org Tue Oct 17 11:19:00 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 17 Oct 2023 11:19:00 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v4] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen wrote: >> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > revert NoReplTest, from @cl4es 's review I've set this PR to require two Reviewers as there is obvious breakage here and no evidence that the tier2 tests have been run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766203522 From lkorinth at openjdk.org Tue Oct 17 12:29:46 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 17 Oct 2023 12:29:46 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v4] In-Reply-To: References: Message-ID: <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com> > Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. > > I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` > > Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: > > /** > * Create ProcessBuilder using the java launcher from the jdk to > * be tested. > * > *

Please observe that you likely should use > * createTestJvm() instead of this method because createTestJvm() > * will add JVM options from "test.vm.opts" and "test.java.opts" > * and this method will not do that. > * > * @param command Arguments to pass to the java command. > * @return The ProcessBuilder instance representing the java command. > */ > > > I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... > > I have run tier 1 testing, and I have started more exhaustive testing. Leo Korinth has updated the pull request incrementally with three additional commits since the last revision: - Revert "8315097: Rename createJavaProcessBuilder" This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317. - Revert "copyright" This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e. - Revert "fix static import" This reverts commit 27da71508aec9a4bec1c0ad07031887286580171. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15452/files - new: https://git.openjdk.org/jdk/pull/15452/files/27da7150..44af07b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=02-03 Stats: 1102 lines in 462 files changed: 11 ins; 22 del; 1069 mod Patch: https://git.openjdk.org/jdk/pull/15452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452 PR: https://git.openjdk.org/jdk/pull/15452 From mgronlun at openjdk.org Tue Oct 17 13:00:24 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 17 Oct 2023 13:00:24 GMT Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket events [v2] In-Reply-To: <8NDoeo0_6Lajo0lBFyDRhy4EO0RoxYbnt7fhOK3ZcGk=.929f4ddb-b828-4101-88da-5ed9faf37627@github.com> References: <8NDoeo0_6Lajo0lBFyDRhy4EO0RoxYbnt7fhOK3ZcGk=.929f4ddb-b828-4101-88da-5ed9faf37627@github.com> Message-ID: On Tue, 17 Oct 2023 10:39:34 GMT, Erik Gahlin wrote: >> Hi, >> >> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. >> >> Testing: jdk/jdk/jfr >> >> Thanks >> Erik > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Update microbenchmark Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15908#pullrequestreview-1682264504 From egahlin at openjdk.org Tue Oct 17 14:03:11 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 17 Oct 2023 14:03:11 GMT Subject: Integrated: 8316927: JFR: Move shouldCommit check earlier for socket events In-Reply-To: References: Message-ID: On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin wrote: > Hi, > > The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. > > Testing: jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: 6aa837ee Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/6aa837eee62c2243689142915abcd85db85d0eed Stats: 55 lines in 5 files changed: 26 ins; 6 del; 23 mod 8316927: JFR: Move shouldCommit check earlier for socket events Reviewed-by: alanb, dfuchs, mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/15908 From rgiulietti at openjdk.org Tue Oct 17 14:12:07 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 17 Oct 2023 14:12:07 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v4] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen wrote: >> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > revert NoReplTest, from @cl4es 's review @wenshao The proposal changes the exception types for seemingly no reason. What concrete problem does this enhancement PR address? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766499191 From duke at openjdk.org Tue Oct 17 14:22:10 2023 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 17 Oct 2023 14:22:10 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v5] In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: > When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: fix from @AlanBateman 's review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16209/files - new: https://git.openjdk.org/jdk/pull/16209/files/cc3bc9ed..f7023991 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=03-04 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209 PR: https://git.openjdk.org/jdk/pull/16209 From duke at openjdk.org Tue Oct 17 14:36:40 2023 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 17 Oct 2023 14:36:40 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v4] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Tue, 17 Oct 2023 14:09:08 GMT, Raffaello Giulietti wrote: > @wenshao The proposal changes the exception types for seemingly no reason. What concrete problem does this enhancement PR address? @lianch 's suggestion in PR #14812 : "Make the NoRepl methods throw IllegalArgument (like NoRepl1 do) by default; move the exception handling logic into Files implementation, the only place where it's actually needed. " We used noRepl in UUID/HexFormat to handle CCE. I felt that the code was not clean enough, so I submitted this PR. After the discussion above, I found that things are not that simple. Should I continue this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766540065 From liach at openjdk.org Tue Oct 17 14:43:52 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 17 Oct 2023 14:43:52 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v4] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Tue, 17 Oct 2023 14:30:26 GMT, Shaojin Wen wrote: > @wenshao The proposal changes the exception types for seemingly no reason. > What concrete problem does this enhancement PR address? @rgiulietti The API was exposed to create a String without duplicating an array in compatible encoding. Initially they are added for Files.readString and writeString, which has a custom exception logic. However, in the coming years, the usages for no-replication has grown, but no other user needs the CCE behavior, which makes code complex. As a result, we are proposing to localize the CCE logoc to Files.readString and writeString so other use sites can call the APIs without try-catch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766561936 From bpb at openjdk.org Tue Oct 17 15:13:22 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 17 Oct 2023 15:13:22 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v6] In-Reply-To: References: Message-ID: On Mon, 9 Oct 2023 21:19:37 GMT, Brian Burkhalter wrote: >> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 4860681: Make test use RandomFactory CSR created, ------------- PR Comment: https://git.openjdk.org/jdk/pull/13744#issuecomment-1766621300 From bpb at openjdk.org Tue Oct 17 15:16:46 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 17 Oct 2023 15:16:46 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data In-Reply-To: References: Message-ID: On Mon, 16 Oct 2023 21:20:17 GMT, Brian Burkhalter wrote: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. This was just a first stab to elicit comments and verify the approach. Note that this would make `minBufferCap` irrelevant. I wonder whether some sort of `@xyzNote` would be appropriate to make that obvious. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1766627675 From bpb at openjdk.org Tue Oct 17 17:29:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 17 Oct 2023 17:29:06 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v6] In-Reply-To: References: Message-ID: On Mon, 9 Oct 2023 21:19:37 GMT, Brian Burkhalter wrote: >> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 4860681: Make test use RandomFactory Please take note of the **API Note** in the new method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13744#issuecomment-1766858873 From rriggs at openjdk.org Tue Oct 17 18:09:59 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 17 Oct 2023 18:09:59 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v5] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: <2s6POSrQenTCvzxYraKH7J4oGJ4UqTiDl5ppDTYZ1fM=.fdb440b4-d33e-46e2-98b5-bd629b2b8c3e@github.com> On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen wrote: >> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix from @AlanBateman 's review Hacking around the exception types isn't a good fix. If the exception is thrown, it is because of a charset conversion error. IllegalArgumentException is for cases where the arguments are incorrect. ------------- Changes requested by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16209#pullrequestreview-1683043411 From bpb at openjdk.org Tue Oct 17 20:00:38 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 17 Oct 2023 20:00:38 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions Message-ID: Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. ------------- Commit messages: - 8298318: (fs) APIs for handling filename extensions Changes: https://git.openjdk.org/jdk/pull/16226/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16226&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298318 Stats: 237 lines in 2 files changed: 236 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16226/head:pull/16226 PR: https://git.openjdk.org/jdk/pull/16226 From bpb at openjdk.org Tue Oct 17 20:00:39 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 17 Oct 2023 20:00:39 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter wrote: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. This request follows from previous work outlined in this [nio-dev thread](https://mail.openjdk.org/pipermail/nio-dev/2023-October/015084.html). For a given `Path` `p`, the following invariant obtains: assert p.equals(p.removeExtension().addExtension(p.getExtension())); Replacing an extension may be accomplished by composing the removal and addition methods as: jshell> Path losslessImage = Path.of("photo.png"); losslessImage ==> photo.png jshell> Path lossyImage = losslessImage.removeExtension().addExtension("jpg"); lossyImage ==> photo.jpg ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1767071295 From bpb at openjdk.org Tue Oct 17 20:07:45 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 17 Oct 2023 20:07:45 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter wrote: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. The UNIX-specific implementation is intentionally omitted for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1767087988 From bpb at openjdk.org Tue Oct 17 21:03:27 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 17 Oct 2023 21:03:27 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions In-Reply-To: References: Message-ID: <0UnMZSi5E4-QLA1kk_IWXkNonWH3DEBQjCWykKIS2JQ=.d7fb2580-7339-4d48-92b6-1917049f49fe@github.com> On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter wrote: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. A CSR will be created once there is reasonable consensus on the verbiage in this conversation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1767164134 From bpb at openjdk.org Wed Oct 18 01:01:27 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Oct 2023 01:01:27 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v2] In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 06:38:38 GMT, Daniel Jeli?ski wrote: > [...] so this PR has potential to make the code much simpler. So simplified in 1d8a667c0160fe9d698773e6bbf8abc2b8ee2596. > src/java.base/share/classes/java/nio/channels/Channels.java line 544: > >> 542: { >> 543: Objects.requireNonNull(ch, "ch"); >> 544: return StreamEncoder.forEncoder(ch, enc.reset(), minBufferCap); > > You could avoid one level of indirection by using `StreamEncoder.forOutputStreamWriter` instead of `new OutputStreamWriter` here. `OutputStreamWriter` is a pass-through wrapper for `StreamEncoder.forOutputStreamWriter` (except for [JDK-6856817](https://bugs.openjdk.org/browse/JDK-6856817) / dc93a924ee4d3b53f0271af577148f8a53eedb57, but that's another story) So changed in c225b9fae846a673d8c372509aa90cd2ead8a3fd. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1767424639 PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1362967985 From bpb at openjdk.org Wed Oct 18 01:01:27 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Oct 2023 01:01:27 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 05:57:37 GMT, Alan Bateman wrote: > [...] you'll need to create to some benchmarks [...] Problems running benchmarks today, likely due to version considerations. Will continue that and if it pans out add tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1767426087 From bpb at openjdk.org Wed Oct 18 01:01:27 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Oct 2023 01:01:27 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v2] In-Reply-To: References: Message-ID: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: - 8306308: Remove WritableByteChannel support from StreamEncoder - 8306308: new OutputStreamWriter -> StreamEncoder.forOutputStreamWriter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16207/files - new: https://git.openjdk.org/jdk/pull/16207/files/808dc885..1d8a667c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=00-01 Stats: 41 lines in 2 files changed: 2 ins; 35 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16207/head:pull/16207 PR: https://git.openjdk.org/jdk/pull/16207 From alanb at openjdk.org Wed Oct 18 06:08:42 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Oct 2023 06:08:42 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions In-Reply-To: References: Message-ID: <4CJmePEjenBJDIH-gd3XR9TvEhASU0aXz0J7KwgSFAs=.457953ba-c679-4fdd-ae89-0ea68fffc71d@github.com> On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter wrote: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. I'm too busy right now to spend time on this one but from a quick glance, the proposed addExtension and removeExtension looks very strange. I think it would be useful to show some examples using them to justify why are needed. Also write out some candidate method names. A Path is immutable so I don't think you want methods with names like addXXX or removeXXX as the resulting usages will look like they mutate the Path. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1767708361 From pminborg at openjdk.org Wed Oct 18 06:20:54 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 18 Oct 2023 06:20:54 GMT Subject: RFR: 8317886: Add @sealedGraph to ByteBuffer In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 13:21:08 GMT, Alan Bateman wrote: > It works well in Buffer as there is a hierarchy to show. It seems a bit confusing to me to have it also show up in the ByteBuffer docs. Have I missed something or what is the reason for doing this? The idea is to have graphs for every sealed class that has at least one publicly permitted class. ByteBuffer has one permitted public class in the form of `MappedByteBuffer`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16142#issuecomment-1767733696 From pminborg at openjdk.org Wed Oct 18 06:20:55 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 18 Oct 2023 06:20:55 GMT Subject: Integrated: 8317886: Add @sealedGraph to ByteBuffer In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 08:59:47 GMT, Per Minborg wrote: > This PR proposed to Add @sealedGraph to `ByteBuffer`. This pull request has now been integrated. Changeset: 8dd80964 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/8dd809642e0e052917451767d2a25dd98b3af3ef Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8317886: Add @sealedGraph to ByteBuffer Reviewed-by: rriggs, iris ------------- PR: https://git.openjdk.org/jdk/pull/16142 From duke at openjdk.org Wed Oct 18 08:29:58 2023 From: duke at openjdk.org (Paul Wagland) Date: Wed, 18 Oct 2023 08:29:58 GMT Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes MaxDirectMemorySize overflow [v6] In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 12:08:02 GMT, Paul Wagland wrote: > @blpb / @AlanBateman : Do you know if this will this also be released to Java 17 and/or Java 21 service packs? PR #227 is for Java 21, so it looks like at least Java 21. Here's hoping also for Java 17 :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1767908247 From alanb at openjdk.org Wed Oct 18 08:47:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Oct 2023 08:47:54 GMT Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes MaxDirectMemorySize overflow [v6] In-Reply-To: References: Message-ID: <23KwigV0-xEFGxnD2a7jAOcegUCERfLB6j8kson0mMc=.c02a3cea-88ed-4997-b745-81c982a7a183@github.com> On Wed, 18 Oct 2023 08:05:55 GMT, Paul Wagland wrote: > > @blpb / @AlanBateman : Do you know if this will this also be released to Java 17 and/or Java 21 service packs? > > PR #227 is for Java 21, so it looks like at least Java 21. Here's hoping also for Java 17 :-) This is not the place to lobby for back ports, I think you are looking for jdk-updates-dev. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1767976677 From mark at lawinegevaar.nl Wed Oct 18 13:03:27 2023 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Wed, 18 Oct 2023 15:03:27 +0200 Subject: Should AbstractInterruptibleChannel.close() still use a synchronized block? Message-ID: Prompted by this Stack Overflow question [https://stackoverflow.com/q/77315894/466862], I'm wondering if the use of a synchronized block in AbstractInterruptibleChannel.close() as-of Java 21 is correct, and shouldn't be replaced with a ReentrantLock or something else. As shown in the question, closing of a channel derived from AbstractInterruptibleChannel can cause pinning of virtual threads. Mark -- Mark Rotteveel From Alan.Bateman at oracle.com Wed Oct 18 13:32:12 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Oct 2023 14:32:12 +0100 Subject: Should AbstractInterruptibleChannel.close() still use a synchronized block? In-Reply-To: References: Message-ID: <72f2ae33-db51-1788-4a56-432695694c87@oracle.com> On 18/10/2023 14:03, Mark Rotteveel wrote: > Prompted by this Stack Overflow question > [https://stackoverflow.com/q/77315894/466862], I'm wondering if the > use of a synchronized block in AbstractInterruptibleChannel.close() > as-of Java 21 is correct, and shouldn't be replaced with a > ReentrantLock or something else. > > As shown in the question, closing of a channel derived from > AbstractInterruptibleChannel can cause pinning of virtual threads. We decided it wasn't worth doing because it's rare to set SO_LINGER. Temporary pinning due to contention on the readLock or writeLock when closing is okay. In the mean-time, we are working to remove restriction on synchronized blocks. We hope to have something in the loom repo soon. -Alan From rriggs at openjdk.org Wed Oct 18 14:24:00 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 18 Oct 2023 14:24:00 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter wrote: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. There are a few builder style APIs for immutable objects that have `withXXX` methods that return an instance with the change requested. A `withExtension(String ext)` could handle the common cases for removing, replacing, and adding an extension. Path p = Path.of("photo.png"); Path base = p.withExtension("") -> "photo" // replaces any extension with the empty extension (and no dot) p.withExtension("jpg") -> "photo.jpg" // replaces the extension base.withExtension("pdf") -> "photo.pdf" // adds the extension Removing an extension with `""` may be a bit unusual, perhaps an additional method would aid discoverablity`basepath()` or `dropExtension`, or `trimExtension`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1768573625 From bpb at openjdk.org Wed Oct 18 14:36:10 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Oct 2023 14:36:10 GMT Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes MaxDirectMemorySize overflow [v6] In-Reply-To: <23KwigV0-xEFGxnD2a7jAOcegUCERfLB6j8kson0mMc=.c02a3cea-88ed-4997-b745-81c982a7a183@github.com> References: <23KwigV0-xEFGxnD2a7jAOcegUCERfLB6j8kson0mMc=.c02a3cea-88ed-4997-b745-81c982a7a183@github.com> Message-ID: On Wed, 18 Oct 2023 08:45:23 GMT, Alan Bateman wrote: > PR #227 is for Java 21, so it looks like at least Java 21. I think you intended https://github.com/openjdk/jdk21u/pull/227. > Here's hoping also for Java 17 :-) I already labelled the issue as being desirable for JDK 17 so it should be on the radar. As @AlanBateman indicated, you can lobby for that on [jdk-updates-dev](https://mail.openjdk.org/pipermail/jdk-updates-dev/) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1768600015 From alanb at openjdk.org Wed Oct 18 14:46:03 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Oct 2023 14:46:03 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v2] In-Reply-To: References: Message-ID: On Wed, 18 Oct 2023 01:01:27 GMT, Brian Burkhalter wrote: >> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. > > Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: > > - 8306308: Remove WritableByteChannel support from StreamEncoder > - 8306308: new OutputStreamWriter -> StreamEncoder.forOutputStreamWriter src/java.base/share/classes/java/nio/channels/Channels.java line 546: > 544: Objects.requireNonNull(enc, "enc"); > 545: return StreamEncoder.forOutputStreamWriter(newOutputStream(ch), > 546: new Object(), enc.reset()); I'm not sure about this lock Object, you may have to add a 2-arg forOutputstreamWriter so that the no-arg Writer is used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1364012165 From bpb at openjdk.org Wed Oct 18 15:05:59 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Oct 2023 15:05:59 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions In-Reply-To: References: Message-ID: <9YzspTburYEbY7hGYqWNmtXGi4-0ikOMPfpbdXS3JrE=.083abb67-1879-494c-8888-64b2f4aad43b@github.com> On Wed, 18 Oct 2023 14:21:32 GMT, Roger Riggs wrote: > There are a few builder style APIs for immutable objects that have `withXXX` methods that return an instance with the change requested. Some time back I thought of but never proposed a method similar to `withExtension(String)` called `modifyExtension(String parameter)` with behavior | path | gus | "" | null | |---------|---------|------|------| | foo.bar | foo.gus | foo. | foo | | foo. | foo.gus | foo. | foo | | foo | foo.gus | foo. | foo | where the 1st column is the path and the 2nd-4th columns are the parameter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1768659315 From coffeys at openjdk.org Wed Oct 18 15:36:01 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 18 Oct 2023 15:36:01 GMT Subject: RFR: 8314891: Additional Zip64 extra header validation [v7] In-Reply-To: <5i8oE7FeOG7W7B2C5jqyKuGNJ_EHf9POIox606GDhzs=.faa3ffd1-6fa6-4a40-984b-a6557e685c0e@github.com> References: <5i8oE7FeOG7W7B2C5jqyKuGNJ_EHf9POIox606GDhzs=.faa3ffd1-6fa6-4a40-984b-a6557e685c0e@github.com> Message-ID: <_Vgd0WYiSEwGjpIiBRdafJEZGZSsKoeSGpZ5g0Kn_5o=.8e185a33-025b-49b0-b624-c92ca1ddc0f4@github.com> On Mon, 18 Sep 2023 13:17:25 GMT, Lance Andersen wrote: >> Please review this PR which improves the Zip64 extra header validation: >> >> - Throw a ZipException If the extra len field is 0 and : >> -- size, csize, or loc offset are set to 0xFFFFFFFF >> -- disk starting number is set to 0xFFFF >> >> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header >> >> Mach5 tiers 1-3 are clean > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Add missing space Looks good to me Lance. I note that the extra checks aren't reversed via any sort of system property but given that this fix isn't planned for JDK update releases, that seems fine to me. early testing by frameworks which create/modify custom zip files will be important. ------------- Marked as reviewed by coffeys (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15650#pullrequestreview-1685425990 From prappo at openjdk.org Wed Oct 18 16:24:00 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 18 Oct 2023 16:24:00 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions In-Reply-To: References: Message-ID: On Wed, 18 Oct 2023 14:21:32 GMT, Roger Riggs wrote: > There are a few builder style APIs for immutable objects that have `withXXX` methods that return an instance with the change requested. A `withExtension(String ext)` could handle the common cases for removing, replacing, and adding an extension. > > ``` > Path p = Path.of("photo.png"); > Path base = p.withExtension("") -> "photo" // replaces any extension with the empty extension (and no dot) > p.withExtension("jpg") -> "photo.jpg" // replaces the extension > base.withExtension("pdf") -> "photo.pdf" // adds the extension > ``` > > Removing an extension with `""` may be a bit unusual, perhaps an additional method would aid discoverablity`basepath()` or `dropExtension`, or `trimExtension`. Right. Depending on how frequent an operation of removing extension is, one could also imagine a name such as `withoutExtension()`. We have methods like that in the JDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1768893893 From rriggs at openjdk.org Wed Oct 18 16:30:59 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 18 Oct 2023 16:30:59 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v5] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen wrote: >> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix from @AlanBateman 's review The new usages that are driving this change would be better served by a method dedicated to creating latin1 strings from a caller provided byte array. The JavaLangAccess shared secret interface is already overused, but it is cleaner, more maintainable, and fit for purpose to add a method than to contort the exception handling as proposed. /** * Return a String constructed using the byte array containing latin1 (ISO-8859-1) characters. * The byte array must not be modified or otherwise referenced or used after the String is created. * If COMPACT_STRINGS is true the coder will be LATIN1 and the byte array is the string value; * otherwise the contents are inflated to create a UTF16 string. */ public String newStringLatin1NoRepl(byte[] src) { if (COMPACT_STRINGS) return new String(src, LATIN1); return new String(StringLatin1.inflate(src, 0, src.length), UTF16); } Creating strings from other encodings that may or have encoding errors should continue to use the current function and handle CCE as required. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1768911569 From alanb at openjdk.org Wed Oct 18 16:43:19 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Oct 2023 16:43:19 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v5] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Wed, 18 Oct 2023 16:27:58 GMT, Roger Riggs wrote: > The new usages that are driving this change would be better served by a method dedicated to creating latin1 strings from a caller provided byte array. The JavaLangAccess shared secret interface is already overused, but it is cleaner, more maintainable, and fit for purpose to add a method than to contort the exception handling as proposed. We have to be very careful with proposals like this as it means code outside of java.lang having access to the underlying bytes. I think other alternatives needs to be explored to avoid this and related concerns. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1768937914 From bpb at openjdk.org Wed Oct 18 16:44:12 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Oct 2023 16:44:12 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter wrote: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. Part of the point of these methods is to cover the various use cases without ever having to deal directly with a period `"."`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1768940324 From rriggs at openjdk.org Wed Oct 18 17:39:13 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 18 Oct 2023 17:39:13 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v5] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Wed, 18 Oct 2023 16:39:47 GMT, Alan Bateman wrote: > We have to be very careful with proposals like this as it means code outside of java.lang having access to the underlying bytes. I think other alternatives needs to be explored to avoid this and related concerns. Yes, adding another method in the "NoRepl" family needs to be done with care and be narrowly focused. JLA already exposes several methods that allow the contents of strings to be read from the underlying value or created from caller provided buffers. All to avoid extra allocations and copying. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1769026087 From tprinzing at openjdk.org Wed Oct 18 18:07:53 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 18 Oct 2023 18:07:53 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops Message-ID: Added jar event support to socket adapters. Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java ------------- Commit messages: - add missing return - socket adapter changes to build with merged master - Merge branch 'master' into JDK-8310978 - fix copyright date - 8310978: JFR events SocektReadEvent and SocketWriteEvent for Socket adaptor ops Changes: https://git.openjdk.org/jdk/pull/16251/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16251&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310978 Stats: 168 lines in 2 files changed: 158 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16251/head:pull/16251 PR: https://git.openjdk.org/jdk/pull/16251 From alanb at openjdk.org Wed Oct 18 18:16:39 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Oct 2023 18:16:39 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops In-Reply-To: References: Message-ID: On Wed, 18 Oct 2023 18:00:40 GMT, Tim Prinzing wrote: > Added jar event support to socket adapters. > > Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java I don't think we should be changing SocketChannelImpl here. Can you look at sun.nio.SocketInputStream and sun.nio.SocketOutputStream - these are the input/output streams for the socket adapter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16251#issuecomment-1769082038 From duke at openjdk.org Wed Oct 18 18:17:24 2023 From: duke at openjdk.org (Glavo) Date: Wed, 18 Oct 2023 18:17:24 GMT Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException [v5] In-Reply-To: References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen wrote: >> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix from @AlanBateman 's review Should we revisit https://github.com/openjdk/jdk/pull/14655? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1769082700 From tprinzing at openjdk.org Wed Oct 18 19:05:21 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 18 Oct 2023 19:05:21 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops In-Reply-To: References: Message-ID: On Wed, 18 Oct 2023 18:00:40 GMT, Tim Prinzing wrote: > Added jar event support to socket adapters. > > Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java okay, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16251#issuecomment-1769147643 From bpb at openjdk.org Wed Oct 18 19:14:46 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Oct 2023 19:14:46 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 05:57:37 GMT, Alan Bateman wrote: > [...] I think you'll need to create to some benchmarks to demonstrate that the channel handling in StreamEncoder can be removed. I don't know whether this was the intended sort of benchmark, @Param({"4096", "8192", "16384", "32768"}) public int capacity; @Setup public void create() throws IOException { cbuf = new char[capacity]; Arrays.fill(cbuf, (char)42); fc = FileChannel.open(path, CREATE, TRUNCATE_EXISTING, WRITE, DSYNC); writer = Channels.newWriter(fc, "UTF-8"); } @Benchmark public char[] testMethod() throws IOException { writer.write(cbuf); return cbuf; } but I see little difference between the master code results: Benchmark (capacity) Mode Cnt Score Error Units MyBenchmark.testMethod 4096 thrpt 5 46120.101 ? 3514.975 ops/s MyBenchmark.testMethod 8192 thrpt 5 23014.621 ? 703.382 ops/s MyBenchmark.testMethod 16384 thrpt 5 11355.081 ? 357.569 ops/s MyBenchmark.testMethod 32768 thrpt 5 5669.087 ? 401.619 ops/s and those with `WritableByteChannel` support removed from `StreamEncoder`: Benchmark (capacity) Mode Cnt Score Error Units MyBenchmark.testMethod 4096 thrpt 5 46431.382 ? 1641.437 ops/s MyBenchmark.testMethod 8192 thrpt 5 23079.163 ? 1333.578 ops/s MyBenchmark.testMethod 16384 thrpt 5 11594.550 ? 793.716 ops/s MyBenchmark.testMethod 32768 thrpt 5 5619.294 ? 1252.580 ops/s ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1769164290 From bpb at openjdk.org Wed Oct 18 20:40:23 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Oct 2023 20:40:23 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v3] In-Reply-To: References: Message-ID: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8306308: Add some code to dispense with lock ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16207/files - new: https://git.openjdk.org/jdk/pull/16207/files/1d8a667c..366e42c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=01-02 Stats: 18 lines in 2 files changed: 16 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16207/head:pull/16207 PR: https://git.openjdk.org/jdk/pull/16207 From bpb at openjdk.org Wed Oct 18 20:40:23 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Oct 2023 20:40:23 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v2] In-Reply-To: References: Message-ID: On Wed, 18 Oct 2023 14:43:04 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8306308: Remove WritableByteChannel support from StreamEncoder >> - 8306308: new OutputStreamWriter -> StreamEncoder.forOutputStreamWriter > > src/java.base/share/classes/java/nio/channels/Channels.java line 546: > >> 544: Objects.requireNonNull(enc, "enc"); >> 545: return StreamEncoder.forOutputStreamWriter(newOutputStream(ch), >> 546: new Object(), enc.reset()); > > I'm not sure about this lock Object, you may have to add a 2-arg forOutputstreamWriter so that the no-arg Writer is used. Done in 366e42c54ef8f04f542f93b5a73a8ad41e60a322. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1364506375 From alanb at openjdk.org Thu Oct 19 07:40:28 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 19 Oct 2023 07:40:28 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v3] In-Reply-To: References: Message-ID: On Wed, 18 Oct 2023 20:40:23 GMT, Brian Burkhalter wrote: >> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8306308: Add some code to dispense with lock I think this looks quite good. BTW: Do we have tests with SocketChannels configured non-blocking that will check that IllegalBlockingMode is thrown? src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 249: > 247: private final int maxBufferCapacity; > 248: > 249: // This must be non-null I think you can drop that comment now, it only made sense when one is non-null. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16207#pullrequestreview-1686940025 PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1770237797 PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1365049207 From djelinski at openjdk.org Thu Oct 19 07:50:26 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 19 Oct 2023 07:50:26 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v3] In-Reply-To: References: Message-ID: On Wed, 18 Oct 2023 20:40:23 GMT, Brian Burkhalter wrote: >> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8306308: Add some code to dispense with lock This is benchmarking disk access. Use a blackhole channel instead: public void create(Blackhole bh) throws IOException { cbuf = new char[capacity]; Arrays.fill(cbuf, (char)42); WritableByteChannel fc = new WritableByteChannel() { @Override public int write(ByteBuffer src) throws IOException { bh.consume(src); int remaining = src.remaining(); src.position(src.limit()); return remaining; } @Override public boolean isOpen() { return true; } @Override public void close() throws IOException { } }; writer = Channels.newWriter(fc, "UTF-8"); } Before: Benchmark (capacity) Mode Cnt Score Error Units WriterBench.testMethod 4096 thrpt 30 7679,273 ? 111,851 ops/ms WriterBench.testMethod 8192 thrpt 30 4194,707 ? 47,489 ops/ms WriterBench.testMethod 16384 thrpt 30 2191,705 ? 46,152 ops/ms WriterBench.testMethod 32768 thrpt 30 1040,875 ? 54,422 ops/ms After: Benchmark (capacity) Mode Cnt Score Error Units WriterBench.testMethod 4096 thrpt 30 7414,422 ? 156,937 ops/ms WriterBench.testMethod 8192 thrpt 30 4161,465 ? 116,885 ops/ms WriterBench.testMethod 16384 thrpt 30 2387,347 ? 37,324 ops/ms WriterBench.testMethod 32768 thrpt 30 1168,550 ? 35,374 ops/ms (well, still no difference) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1770252093 From djelinski at openjdk.org Thu Oct 19 08:05:13 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 19 Oct 2023 08:05:13 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v3] In-Reply-To: References: Message-ID: On Wed, 18 Oct 2023 20:40:23 GMT, Brian Burkhalter wrote: >> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8306308: Add some code to dispense with lock LGTM src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 1: > 1: /* There's a couple of null checks that can be removed now: https://github.com/openjdk/jdk/blob/366e42c54ef8f04f542f93b5a73a8ad41e60a322/src/java.base/share/classes/sun/nio/cs/StreamEncoder.java#L393 https://github.com/openjdk/jdk/blob/366e42c54ef8f04f542f93b5a73a8ad41e60a322/src/java.base/share/classes/sun/nio/cs/StreamEncoder.java#L415 ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16207#pullrequestreview-1686980026 PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1365075364 From bpb at openjdk.org Thu Oct 19 15:09:52 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 19 Oct 2023 15:09:52 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v3] In-Reply-To: References: Message-ID: On Thu, 19 Oct 2023 07:38:24 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8306308: Add some code to dispense with lock > > BTW: Do we have tests with SocketChannels configured non-blocking that will check that IllegalBlockingMode is thrown? @AlanBateman and @djelinski thanks for all the comments. I will address them and add test coverage, which I inteentionally deferred. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1771141208 From lkorinth at openjdk.org Thu Oct 19 15:16:13 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 19 Oct 2023 15:16:13 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v5] In-Reply-To: References: Message-ID: > Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. > > I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` > > Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: > > /** > * Create ProcessBuilder using the java launcher from the jdk to > * be tested. > * > *

Please observe that you likely should use > * createTestJvm() instead of this method because createTestJvm() > * will add JVM options from "test.vm.opts" and "test.java.opts" > * and this method will not do that. > * > * @param command Arguments to pass to the java command. > * @return The ProcessBuilder instance representing the java command. > */ > > > I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... > > I have run tier 1 testing, and I have started more exhaustive testing. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Batch update using sed find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g" find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g" find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g" - Merge branch '_master_jdk' into _8315097 - explain usage - Revert "8315097: Rename createJavaProcessBuilder" This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317. - Revert "copyright" This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e. - Revert "fix static import" This reverts commit 27da71508aec9a4bec1c0ad07031887286580171. - fix static import - copyright - 8315097: Rename createJavaProcessBuilder ------------- Changes: https://git.openjdk.org/jdk/pull/15452/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=04 Stats: 894 lines in 560 files changed: 34 ins; 10 del; 850 mod Patch: https://git.openjdk.org/jdk/pull/15452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452 PR: https://git.openjdk.org/jdk/pull/15452 From lkorinth at openjdk.org Thu Oct 19 15:16:42 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 19 Oct 2023 15:16:42 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v4] In-Reply-To: <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com> References: <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com> Message-ID: <3XTw5IAFj_YpaMrqyLdO9mNbWDENFMVkwk8JBmKHDcE=.5e4b1c70-0b36-4ff5-9cce-ee4f25a8e3bb@github.com> On Tue, 17 Oct 2023 12:29:46 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with three additional commits since the last revision: > > - Revert "8315097: Rename createJavaProcessBuilder" > > This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317. > - Revert "copyright" > > This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e. > - Revert "fix static import" > > This reverts commit 27da71508aec9a4bec1c0ad07031887286580171. If this looks roughly acceptable, I will manually add indentation spaces. I am now running tests. The changes can be verified by running the following commands: git switch -c _reproduce 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9 find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g" find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g" find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g" git diff HEAD f80dda8d7109c2ef6bc1f685d0b611704dec645e Only the documentation changes should be visible. When I have manually indented everything it should be easy to that verify that change as a whitespace-only change. But that is for tomorrow (at best). ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1771194189 From bpb at openjdk.org Thu Oct 19 21:54:15 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 19 Oct 2023 21:54:15 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v3] In-Reply-To: References: Message-ID: On Thu, 19 Oct 2023 07:47:52 GMT, Daniel Jeli?ski wrote: > (well, still no difference) Likewise. Before: Benchmark (capacity) Mode Cnt Score Error Units WriterBench.testMethod 4096 thrpt 5 7896495.475 ? 109101.117 ops/s WriterBench.testMethod 8192 thrpt 5 3507455.124 ? 125380.018 ops/s WriterBench.testMethod 16384 thrpt 5 1761486.228 ? 57484.438 ops/s WriterBench.testMethod 32768 thrpt 5 897733.089 ? 88233.815 ops/s After: Benchmark (capacity) Mode Cnt Score Error Units WriterBench.testMethod 4096 thrpt 5 7383045.614 ? 72860.403 ops/s WriterBench.testMethod 8192 thrpt 5 4073733.378 ? 30800.651 ops/s WriterBench.testMethod 16384 thrpt 5 1789169.956 ? 183912.728 ops/s WriterBench.testMethod 32768 thrpt 5 848052.004 ? 113203.131 ops/s I don't know why the measurements have such a large numerical difference however. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1771756386 From bpb at openjdk.org Thu Oct 19 22:26:13 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 19 Oct 2023 22:26:13 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v4] In-Reply-To: References: Message-ID: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8306308: Remove obsolete comment and null checks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16207/files - new: https://git.openjdk.org/jdk/pull/16207/files/366e42c5..cbf23b9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16207/head:pull/16207 PR: https://git.openjdk.org/jdk/pull/16207 From bpb at openjdk.org Thu Oct 19 22:26:13 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 19 Oct 2023 22:26:13 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v3] In-Reply-To: References: Message-ID: <1komKnaDQKSxKaJkFIxJ-iTpRWkUDwZSQQMebsOT5OE=.e68c4612-0a08-45ff-a18d-6af28e66a35b@github.com> On Thu, 19 Oct 2023 21:51:27 GMT, Brian Burkhalter wrote: > I don't know why the measurements have such a large numerical difference however. D'oh: `ops/s` instead of `ops/ms`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1771781723 From bpb at openjdk.org Thu Oct 19 22:26:14 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 19 Oct 2023 22:26:14 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v3] In-Reply-To: References: Message-ID: On Thu, 19 Oct 2023 07:59:29 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8306308: Add some code to dispense with lock > > src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 1: > >> 1: /* > > There's a couple of null checks that can be removed now: > https://github.com/openjdk/jdk/blob/366e42c54ef8f04f542f93b5a73a8ad41e60a322/src/java.base/share/classes/sun/nio/cs/StreamEncoder.java#L393 > https://github.com/openjdk/jdk/blob/366e42c54ef8f04f542f93b5a73a8ad41e60a322/src/java.base/share/classes/sun/nio/cs/StreamEncoder.java#L415 Removed in cbf23b9f2942a5315bc160f0f653348c0d3aeee7. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1366197623 From bpb at openjdk.org Thu Oct 19 22:26:14 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 19 Oct 2023 22:26:14 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v3] In-Reply-To: References: Message-ID: On Thu, 19 Oct 2023 07:37:22 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8306308: Add some code to dispense with lock > > src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 249: > >> 247: private final int maxBufferCapacity; >> 248: >> 249: // This must be non-null > > I think you can drop that comment now, it only made sense when one is non-null. Dropped in cbf23b9f2942a5315bc160f0f653348c0d3aeee7. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1366197318 From bpb at openjdk.org Thu Oct 19 23:46:03 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 19 Oct 2023 23:46:03 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v5] In-Reply-To: References: Message-ID: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8306308: Add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16207/files - new: https://git.openjdk.org/jdk/pull/16207/files/cbf23b9f..24f65b6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=03-04 Stats: 182 lines in 2 files changed: 182 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16207/head:pull/16207 PR: https://git.openjdk.org/jdk/pull/16207 From bpb at openjdk.org Thu Oct 19 23:46:04 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 19 Oct 2023 23:46:04 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v3] In-Reply-To: References: Message-ID: On Thu, 19 Oct 2023 07:38:24 GMT, Alan Bateman wrote: > BTW: Do we have tests with SocketChannels configured non-blocking that will check that IllegalBlockingMode is thrown? The test I just added should cover this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1771844131 From bpb at openjdk.org Thu Oct 19 23:46:04 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 19 Oct 2023 23:46:04 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v3] In-Reply-To: References: Message-ID: <2vpOZ_yfxZ7rhAQMuLcOEpag59oyapwlmpvbs2O0VqQ=.a23952a3-4281-43a7-b649-cc96dbd37627@github.com> On Thu, 19 Oct 2023 07:50:32 GMT, Daniel Jeli?ski wrote: >> BTW: Do we have tests with SocketChannels configured non-blocking that will check that IllegalBlockingMode is thrown? > >> Do we have tests with SocketChannels configured non-blocking that will check that IllegalBlockingMode is thrown? > > I don't believe we do; the code attached to the JBS ticket suggests that we did not throw, so if we had such a test, it would be failing. The test I added is just the reproducers attached by @djelinski (thanks!) to the JDK-8306308 issue aggregated into a single JUnit 5 test. Both sub-tests fail when run against the master branch, but pass with the proposed change applied. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1771846044 From djelinski at openjdk.org Fri Oct 20 06:45:40 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 20 Oct 2023 06:45:40 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v5] In-Reply-To: References: Message-ID: On Thu, 19 Oct 2023 23:46:03 GMT, Brian Burkhalter wrote: >> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8306308: Add test Changes requested by djelinski (Reviewer). ` line 1: > (failed to retrieve contents of file, check the PR for context) This filename doesn't look good ------------- PR Review: https://git.openjdk.org/jdk/pull/16207#pullrequestreview-1689336359 PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1366535724 From alanb at openjdk.org Fri Oct 20 07:28:40 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 20 Oct 2023 07:28:40 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v5] In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 06:36:05 GMT, Daniel Jeli?ski wrote: > This filename doesn't look good I think something has been fat-fingered and the test is added a second time in the root directory with a tick in the name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1366578141 From lkorinth at openjdk.org Fri Oct 20 08:34:35 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 20 Oct 2023 08:34:35 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v5] In-Reply-To: References: Message-ID: On Thu, 19 Oct 2023 15:16:13 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Batch update using sed > > find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g" > find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g" > find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g" > - Merge branch '_master_jdk' into _8315097 > - explain usage > - Revert "8315097: Rename createJavaProcessBuilder" > > This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317. > - Revert "copyright" > > This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e. > - Revert "fix static import" > > This reverts commit 27da71508aec9a4bec1c0ad07031887286580171. > - fix static import > - copyright > - 8315097: Rename createJavaProcessBuilder Just ignore what I just pushed, I will have a new version out sorry... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1772309579 PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1772309992 From alanb at openjdk.org Fri Oct 20 10:27:41 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 20 Oct 2023 10:27:41 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v5] In-Reply-To: References: Message-ID: On Thu, 19 Oct 2023 23:46:03 GMT, Brian Burkhalter wrote: >> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8306308: Add test test/jdk/java/nio/channels/Channels/NewWriter.java line 84: > 82: () -> { > 83: try (ServerSocket ss = new ServerSocket(0); > 84: SocketChannel cs = SocketChannel.open(new InetSocketAddress(ss.getLocalPort()))) { You probably should bind the SeverSocket to the loopback address to avoid interference from other machines. I assume this should be "sc" (for SocketChannel) rather than "cs". The naming of the test methods looks a bit strange too, did you mean both to have an uppercase character as the first character? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1366787499 From duke at openjdk.org Fri Oct 20 11:38:40 2023 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 20 Oct 2023 11:38:40 GMT Subject: Withdrawn: 8318200: String::newStringNoRepl and String::getBytesNoRepl does not throw CharacterCodingException In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com> Message-ID: On Mon, 16 Oct 2023 22:27:34 GMT, Shaojin Wen wrote: > When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/16209 From bpb at openjdk.org Fri Oct 20 15:43:40 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 15:43:40 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v5] In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 07:25:46 GMT, Alan Bateman wrote: >> ` line 1: >> >>> (failed to retrieve contents of file, check the PR for context) >> This filename doesn't look good > >> This filename doesn't look good > > I think something has been fat-fingered and the test is added a second time in the root directory with a tick in the name. Damn. Git was giving me problems about some untracked file and I thought I fixed. I'll look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367162079 From bpb at openjdk.org Fri Oct 20 15:58:56 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 15:58:56 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v6] In-Reply-To: References: Message-ID: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8306308: Remove spurious file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16207/files - new: https://git.openjdk.org/jdk/pull/16207/files/24f65b6c..68b07597 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=04-05 Stats: 84 lines in 1 file changed: 0 ins; 84 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16207/head:pull/16207 PR: https://git.openjdk.org/jdk/pull/16207 From alanb at openjdk.org Fri Oct 20 16:24:42 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 20 Oct 2023 16:24:42 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v5] In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 10:24:22 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8306308: Add test > > test/jdk/java/nio/channels/Channels/NewWriter.java line 84: > >> 82: () -> { >> 83: try (ServerSocket ss = new ServerSocket(0); >> 84: SocketChannel cs = SocketChannel.open(new InetSocketAddress(ss.getLocalPort()))) { > > You probably should bind the SeverSocket to the loopback address to avoid interference from other machines. > > I assume this should be "sc" (for SocketChannel) rather than "cs". The naming of the test methods looks a bit strange too, did you mean both to have an uppercase character as the first character? I think this is close to what you want here: try (ServerSocket ss = new ServerSocket(); SocketChannel sc = SocketChannel.open()) { InetAddress lb = InetAddress.getLoopbackAddress(); ss.bind(new InetSocketAddress(lb, 0)); sc.connect(ss.getLocalSocketAddress()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367216253 From bpb at openjdk.org Fri Oct 20 16:37:54 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 16:37:54 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v7] In-Reply-To: References: Message-ID: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8306308: Fix test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16207/files - new: https://git.openjdk.org/jdk/pull/16207/files/68b07597..f1b74f08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=05-06 Stats: 23 lines in 1 file changed: 7 ins; 1 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/16207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16207/head:pull/16207 PR: https://git.openjdk.org/jdk/pull/16207 From bpb at openjdk.org Fri Oct 20 16:37:55 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 16:37:55 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v5] In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 15:40:35 GMT, Brian Burkhalter wrote: >>> This filename doesn't look good >> >> I think something has been fat-fingered and the test is added a second time in the root directory with a tick in the name. > > Damn. Git was giving me problems about some untracked file and I thought I fixed. I'll look. I hope the finger is less fat in 68b07597a53e1271a66bea97c0fac0644dc15b7d. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367227304 From bpb at openjdk.org Fri Oct 20 16:37:59 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 16:37:59 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v5] In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 16:22:10 GMT, Alan Bateman wrote: >> test/jdk/java/nio/channels/Channels/NewWriter.java line 84: >> >>> 82: () -> { >>> 83: try (ServerSocket ss = new ServerSocket(0); >>> 84: SocketChannel cs = SocketChannel.open(new InetSocketAddress(ss.getLocalPort()))) { >> >> You probably should bind the SeverSocket to the loopback address to avoid interference from other machines. >> >> I assume this should be "sc" (for SocketChannel) rather than "cs". The naming of the test methods looks a bit strange too, did you mean both to have an uppercase character as the first character? > > I think this is close to what you want here: > > try (ServerSocket ss = new ServerSocket(); > SocketChannel sc = SocketChannel.open()) { > > InetAddress lb = InetAddress.getLoopbackAddress(); > ss.bind(new InetSocketAddress(lb, 0)); > sc.connect(ss.getLocalSocketAddress()); I had already committed f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367228369 From alanb at openjdk.org Fri Oct 20 16:45:32 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 20 Oct 2023 16:45:32 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v5] In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 16:34:28 GMT, Brian Burkhalter wrote: >> I think this is close to what you want here: >> >> try (ServerSocket ss = new ServerSocket(); >> SocketChannel sc = SocketChannel.open()) { >> >> InetAddress lb = InetAddress.getLoopbackAddress(); >> ss.bind(new InetSocketAddress(lb, 0)); >> sc.connect(ss.getLocalSocketAddress()); > > I had already committed f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed? > I had already committed https://github.com/openjdk/jdk/commit/f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed? Your change binds the connecting socket, it's the listener socket that should be bound to the loopback. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367237231 From bpb at openjdk.org Fri Oct 20 16:45:33 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 16:45:33 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v5] In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 16:40:06 GMT, Alan Bateman wrote: >> I had already committed f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed? > >> I had already committed https://github.com/openjdk/jdk/commit/f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed? > > Your change binds the connecting socket, it's the listener socket that should be bound to the loopback. Thanks, will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367241075 From bpb at openjdk.org Fri Oct 20 16:58:12 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 16:58:12 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v8] In-Reply-To: References: Message-ID: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8306308: Really fix test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16207/files - new: https://git.openjdk.org/jdk/pull/16207/files/f1b74f08..850ffd6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=06-07 Stats: 16 lines in 1 file changed: 1 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/16207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16207/head:pull/16207 PR: https://git.openjdk.org/jdk/pull/16207 From bpb at openjdk.org Fri Oct 20 16:58:12 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 16:58:12 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v5] In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 16:42:32 GMT, Brian Burkhalter wrote: >>> I had already committed https://github.com/openjdk/jdk/commit/f1b74f084cabbece4c7b19b9f404fddfa2e9b45d before I saw this comment, Should that be changed? >> >> Your change binds the connecting socket, it's the listener socket that should be bound to the loopback. > > Thanks, will fix. I hope it is correct now in 850ffd6be3010a08bbcd99041a114f994f8f4993. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367261237 From djelinski at openjdk.org Fri Oct 20 17:38:35 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 20 Oct 2023 17:38:35 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v8] In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 16:58:12 GMT, Brian Burkhalter wrote: >> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8306308: Really fix test test/jdk/java/nio/channels/Channels/NewWriter.java line 76: > 74: writer.flush(); > 75: System.out.println(i); > 76: actual++; incrementing `actual` here feels weird; could you remove this, and adjust EXPECTED instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367319545 From bpb at openjdk.org Fri Oct 20 17:47:37 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 17:47:37 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v8] In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 17:35:42 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8306308: Really fix test > > test/jdk/java/nio/channels/Channels/NewWriter.java line 76: > >> 74: writer.flush(); >> 75: System.out.println(i); >> 76: actual++; > > incrementing `actual` here feels weird; could you remove this, and adjust EXPECTED instead? Yeah I think you are right; will do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367327488 From bpb at openjdk.org Fri Oct 20 17:56:10 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 17:56:10 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v9] In-Reply-To: References: Message-ID: <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com> > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8306308: Make EXPECTED less unexpected ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16207/files - new: https://git.openjdk.org/jdk/pull/16207/files/850ffd6b..d246a4b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16207&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16207/head:pull/16207 PR: https://git.openjdk.org/jdk/pull/16207 From djelinski at openjdk.org Fri Oct 20 17:56:10 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 20 Oct 2023 17:56:10 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v9] In-Reply-To: <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com> References: <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com> Message-ID: <3yNuJ_dfJp3WV6AatvYhJQLHSKxYgVnkOXzKkrM92WA=.8444deb2-13c2-447e-badc-a1bd9d060e69@github.com> On Fri, 20 Oct 2023 17:52:36 GMT, Brian Burkhalter wrote: >> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8306308: Make EXPECTED less unexpected Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16207#pullrequestreview-1690640428 From bpb at openjdk.org Fri Oct 20 17:56:10 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 17:56:10 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v8] In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 17:44:30 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/channels/Channels/NewWriter.java line 76: >> >>> 74: writer.flush(); >>> 75: System.out.println(i); >>> 76: actual++; >> >> incrementing `actual` here feels weird; could you remove this, and adjust EXPECTED instead? > > Yeah I think you are right; will do. Changed in d246a4b6ebfafa9d3fb15c97cffad334ff7f9f91; thanks, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367331734 From bpb at openjdk.org Fri Oct 20 21:15:47 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 21:15:47 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v9] In-Reply-To: <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com> References: <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com> Message-ID: On Fri, 20 Oct 2023 17:56:10 GMT, Brian Burkhalter wrote: >> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8306308: Make EXPECTED less unexpected Tiers 1-3 passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16207#issuecomment-1773399786 From bpb at openjdk.org Fri Oct 20 21:15:49 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Oct 2023 21:15:49 GMT Subject: Integrated: 8306308: (ch) Writer created by Channels::newWriter may lose data In-Reply-To: References: Message-ID: On Mon, 16 Oct 2023 21:20:17 GMT, Brian Burkhalter wrote: > Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. This pull request has now been integrated. Changeset: a1a62d99 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/a1a62d9964393533eeab269d1f405c8f0db1e900 Stats: 139 lines in 3 files changed: 104 ins; 22 del; 13 mod 8306308: (ch) Writer created by Channels::newWriter may lose data Reviewed-by: djelinski, alanb ------------- PR: https://git.openjdk.org/jdk/pull/16207 From alanb at openjdk.org Sat Oct 21 08:41:47 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 21 Oct 2023 08:41:47 GMT Subject: RFR: 8306308: (ch) Writer created by Channels::newWriter may lose data [v9] In-Reply-To: <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com> References: <63EuPvDPOEugih-3w_GNJJ3nJ_UsFguqrdeZlkv39Uo=.844c2c6c-f513-419d-a3e1-a5cf660e5b08@github.com> Message-ID: On Fri, 20 Oct 2023 17:56:10 GMT, Brian Burkhalter wrote: >> Change `Channels.newWriter` to return a `Writer` created by first wrapping the `WritableByteChannel` in an `OutputStream` using `Channels.newOutputStream` and then wrapping the result in an `OutputStreamWriter`. With this change in place, the problems reported in the issue do not occur. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8306308: Make EXPECTED less unexpected test/jdk/java/nio/channels/Channels/NewWriter.java line 96: > 94: StandardCharsets.UTF_8)) { > 95: for (int i = 1; i < Integer.MAX_VALUE; i++) { > 96: writer.write("test" + i); There's no need to set SO_SNDBUF here, the IBME should be thrown then the writer attempts to flush. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16207#discussion_r1367690958 From pminborg at openjdk.org Mon Oct 23 07:30:37 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 23 Oct 2023 07:30:37 GMT Subject: RFR: 8316660: (fs) Files.lines implementation can use MemorySegment for file mapping [v7] In-Reply-To: References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com> Message-ID: On Thu, 21 Sep 2023 16:24:22 GMT, Per Minborg wrote: >> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in the `Files::lines` implementation (in the internal class `FileChannelLinesSpliterator`). >> >> The old solution deterministically unmapped the `ByteBuffer` if closed. If not closed, the `ByteBuffer` would be GC:ed. >> >> This proposal mimics the old behavior but may hold the mapped memory region slightly longer. >> >> Tested and passed tier1, tier2, tier3 > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Reformat Keep alive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15814#issuecomment-1774584634 From duke at openjdk.org Mon Oct 23 14:43:45 2023 From: duke at openjdk.org (duke) Date: Mon, 23 Oct 2023 14:43:45 GMT Subject: Withdrawn: JDK-8314115: DatagramSocket.receive may hang if underlying UDP RCVBUF of OS is too small In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 11:37:23 GMT, Thomas Obermeier wrote: > docu update to explain that receive can hang because of bad configuration This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15401 From lancea at openjdk.org Mon Oct 23 19:12:57 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 23 Oct 2023 19:12:57 GMT Subject: RFR: 8314891: Additional Zip64 extra header validation [v8] In-Reply-To: References: Message-ID: > Please review this PR which improves the Zip64 extra header validation: > > - Throw a ZipException If the extra len field is 0 and : > -- size, csize, or loc offset are set to 0xFFFFFFFF > -- disk starting number is set to 0xFFFF > > - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header > > Mach5 tiers 1-3 are clean Lance Andersen 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 ten additional commits since the last revision: - Merge branch 'master' into JDK-8314891 - Add missing space - Revamp isZip64ExtBlockSizeValid - Merge branch 'master' into JDK-8314891 - Merge branch 'master' into JDK-8314891 - Remove tab(s) from comment - Added additional tests, along with additional cleanup and refactoring - Clean up some minor formatting issues - Additional Zip64 extra header validation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15650/files - new: https://git.openjdk.org/jdk/pull/15650/files/208a5ecc..255aec85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15650&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15650&range=06-07 Stats: 75854 lines in 1953 files changed: 44906 ins; 19381 del; 11567 mod Patch: https://git.openjdk.org/jdk/pull/15650.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15650/head:pull/15650 PR: https://git.openjdk.org/jdk/pull/15650 From bpb at openjdk.org Mon Oct 23 22:09:45 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 23 Oct 2023 22:09:45 GMT Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter Message-ID: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test. ------------- Commit messages: - 8318677: Add impl note and slightly tweak the test Changes: https://git.openjdk.org/jdk/pull/16325/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16325&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318677 Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16325/head:pull/16325 PR: https://git.openjdk.org/jdk/pull/16325 From tprinzing at openjdk.org Mon Oct 23 22:35:55 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Mon, 23 Oct 2023 22:35:55 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v2] In-Reply-To: References: Message-ID: > Added jar event support to socket adapters. > > Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: requested change to location of socket adaptor event logic bring back event offer semantics where it was fine. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16251/files - new: https://git.openjdk.org/jdk/pull/16251/files/05aed00a..06e35acf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16251&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16251&range=00-01 Stats: 123 lines in 5 files changed: 62 ins; 52 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/16251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16251/head:pull/16251 PR: https://git.openjdk.org/jdk/pull/16251 From alanb at openjdk.org Tue Oct 24 06:53:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 24 Oct 2023 06:53:36 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v2] In-Reply-To: References: Message-ID: <5N015laYjUrZtD_doT7qPjiIIqXdkYQ7CW7T7Zmtmpo=.bb003d03-594f-4602-8e6e-5c21a0742fd6@github.com> On Mon, 23 Oct 2023 22:35:55 GMT, Tim Prinzing wrote: >> Added jar event support to socket adapters. >> >> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > requested change to location of socket adaptor event logic > > bring back event offer semantics where it was fine. src/java.base/share/classes/sun/nio/ch/SocketInputStream.java line 82: > 80: long start = SocketReadEvent.timestamp(); > 81: int n = implRead(b, off, len); > 82: SocketReadEvent.offer(start, n, sc.remoteAddress(), timeoutSupplier.getAsInt()); One of the things left over from the original refactoring was to dig into my the event needs the timeout, it would be nice if that could go away. For now, I'd prefer if the timeout could be captured once as otherwise there is no guarantee that the event will be reported with the same timeout used for the socket read. In other words, add a timeout parameter to implRead so that the method calls implRead with the timeout, avoids calling timeoutSuppler::getAsInt twice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369695891 From lkorinth at openjdk.org Tue Oct 24 07:49:30 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 24 Oct 2023 07:49:30 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6] In-Reply-To: References: Message-ID: > Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. > > I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` > > Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: > > /** > * Create ProcessBuilder using the java launcher from the jdk to > * be tested. > * > *

Please observe that you likely should use > * createTestJvm() instead of this method because createTestJvm() > * will add JVM options from "test.vm.opts" and "test.java.opts" > * and this method will not do that. > * > * @param command Arguments to pass to the java command. > * @return The ProcessBuilder instance representing the java command. > */ > > > I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... > > I have run tier 1 testing, and I have started more exhaustive testing. Leo Korinth has updated the pull request incrementally with six additional commits since the last revision: - static import - copyright - whitespace - whitespace - sed - fix test/lib/jdk/test/lib/process/ProcessTools.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15452/files - new: https://git.openjdk.org/jdk/pull/15452/files/f80dda8d..2f57a32d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=04-05 Stats: 1580 lines in 560 files changed: 44 ins; 34 del; 1502 mod Patch: https://git.openjdk.org/jdk/pull/15452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452 PR: https://git.openjdk.org/jdk/pull/15452 From alanb at openjdk.org Tue Oct 24 08:15:38 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 24 Oct 2023 08:15:38 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v2] In-Reply-To: References: Message-ID: On Mon, 23 Oct 2023 22:35:55 GMT, Tim Prinzing wrote: >> Added jar event support to socket adapters. >> >> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > requested change to location of socket adaptor event logic > > bring back event offer semantics where it was fine. test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 68: > 66: public void test() throws Throwable { > 67: try (Recording recording = new Recording()) { > 68: try (ServerSocketChannel ss = ServerSocketChannel.open()) { Did you mean to name a ServerSocketChannel "ss", other tests use "ssc". test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 74: > 72: > 73: ss.socket().setReuseAddress(true); > 74: ss.socket().bind(null); Tests usually bind to the loopback address to reduce interference from other programs in the environment. Also ServerSocketChannel defines the bind method so you can do this: InetAddress lb = InetAddress.getLoopbackAddress(); ssc.bind(new InetSocketAddress(lb, 0)); test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 103: > 101: readerThread.start(); > 102: > 103: try (SocketChannel sc = SocketChannel.open(ss.socket().getLocalSocketAddress()); Socket s = sc.socket(); OutputStream os = s.getOutputStream()) { If you put a line break after each ; then it would be easier to read. Also you can use ssc.getLocalAddress(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369775585 PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369777836 PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369779900 From alanb at openjdk.org Tue Oct 24 08:45:29 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 24 Oct 2023 08:45:29 GMT Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter In-Reply-To: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> Message-ID: On Mon, 23 Oct 2023 22:03:35 GMT, Brian Burkhalter wrote: > Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test. src/java.base/share/classes/java/nio/channels/Channels.java line 427: > 425: * > 426: * @implNote > 427: * The implementation may ignore the value of {@code minBufferCap} provided. I think we'll need to adjust the specification of parameter too, something like "may be ignored". For the implNote I think it can just sat that minBufferCap is ignored. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16325#discussion_r1369817302 From lkorinth at openjdk.org Tue Oct 24 09:10:43 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 24 Oct 2023 09:10:43 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6] In-Reply-To: References: Message-ID: On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with six additional commits since the last revision: > > - static import > - copyright > - whitespace > - whitespace > - sed > - fix test/lib/jdk/test/lib/process/ProcessTools.java Hi, if you want to see what I have modified manually, you can do my sed commands and compare to this pull request: git switch -c _reproduce 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9 find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedTestJavaProcessBuilder(/g" find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createTestJavaProcessBuilder(/g" find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedTestJavaProcessBuilder/g" find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createTestJvm/import static jdk.test.lib.process.ProcessTools.createTestJavaProcessBuilder/g" git add -u; git commit -m sed git diff-tree --no-commit-id --name-only -r 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9..HEAD | xargs sed -i -e "s%^( * Copyright (c) ....)[^[:alpha:]]*(Oracle.*)%\1, 2023, \2%" git ls-files -m | xargs sed -i -e "s%(Copyright (c) 2023), 2023, (Oracle.*)%\1, \2%" git add -u; git commit -m copyright git diff HEAD 2f57a32df8d17da51a04177563327ca2a75e8061 It will give you an easier way to review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1776817287 From stefank at openjdk.org Tue Oct 24 09:51:39 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 24 Oct 2023 09:51:39 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6] In-Reply-To: References: Message-ID: On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with six additional commits since the last revision: > > - static import > - copyright > - whitespace > - whitespace > - sed > - fix test/lib/jdk/test/lib/process/ProcessTools.java Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1694437335 From egahlin at openjdk.org Tue Oct 24 10:42:38 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 24 Oct 2023 10:42:38 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v2] In-Reply-To: <5N015laYjUrZtD_doT7qPjiIIqXdkYQ7CW7T7Zmtmpo=.bb003d03-594f-4602-8e6e-5c21a0742fd6@github.com> References: <5N015laYjUrZtD_doT7qPjiIIqXdkYQ7CW7T7Zmtmpo=.bb003d03-594f-4602-8e6e-5c21a0742fd6@github.com> Message-ID: On Tue, 24 Oct 2023 06:50:22 GMT, Alan Bateman wrote: >> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: >> >> requested change to location of socket adaptor event logic >> >> bring back event offer semantics where it was fine. > > src/java.base/share/classes/sun/nio/ch/SocketInputStream.java line 82: > >> 80: long start = SocketReadEvent.timestamp(); >> 81: int n = implRead(b, off, len); >> 82: SocketReadEvent.offer(start, n, sc.remoteAddress(), timeoutSupplier.getAsInt()); > > One of the things left over from the original refactoring was to dig into why the event needs the timeout, it would be nice if that could go away. > > For now, I'd prefer if the timeout could be captured once as otherwise there is no guarantee that the event will be reported with the same timeout used for the socket read. In other words, add a timeout parameter to implRead so that the method calls implRead with the timeout, avoids calling timeoutSuppler::getAsInt twice. I think SocketRead.emit() have several advantages: - No need execute remoteAddress() when the threshold don't exceed 20 ms - Avoid the synchronized block in SocketChannelImpl::remoteAddress(). - The end time is taken more close to start time. - One less frame for JFR to walk The disadvantage is some code repetition, but it's not that much. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369960907 From alanb at openjdk.org Tue Oct 24 10:54:35 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 24 Oct 2023 10:54:35 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v2] In-Reply-To: References: <5N015laYjUrZtD_doT7qPjiIIqXdkYQ7CW7T7Zmtmpo=.bb003d03-594f-4602-8e6e-5c21a0742fd6@github.com> Message-ID: <87839VyAwVQ6KLx0r9gBg-0AweqeTOuk3JQusUrGz_w=.1615e7c5-0a60-4c2c-96fb-a9e99ce5492b@github.com> On Tue, 24 Oct 2023 10:40:11 GMT, Erik Gahlin wrote: >> src/java.base/share/classes/sun/nio/ch/SocketInputStream.java line 82: >> >>> 80: long start = SocketReadEvent.timestamp(); >>> 81: int n = implRead(b, off, len); >>> 82: SocketReadEvent.offer(start, n, sc.remoteAddress(), timeoutSupplier.getAsInt()); >> >> One of the things left over from the original refactoring was to dig into why the event needs the timeout, it would be nice if that could go away. >> >> For now, I'd prefer if the timeout could be captured once as otherwise there is no guarantee that the event will be reported with the same timeout used for the socket read. In other words, add a timeout parameter to implRead so that the method calls implRead with the timeout, avoids calling timeoutSuppler::getAsInt twice. > > I think SocketRead.emit() have several advantages: > > - No need execute remoteAddress() when the threshold don't exceed 20 ms > - Avoid the synchronized block in SocketChannelImpl::remoteAddress(). > - The end time is taken more close to start time. > - One less frame for JFR to walk > > The disadvantage is some code repetition, but it's not that much. If remoteAddress is an issue then we can look at that, it may be a candidate to a `@Stable` field. That is probably beyond the scope of this PR of course. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1369973343 From bpb at openjdk.org Tue Oct 24 16:36:52 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 24 Oct 2023 16:36:52 GMT Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter [v2] In-Reply-To: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> Message-ID: > Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8318677: Adjust minBufferap verbiage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16325/files - new: https://git.openjdk.org/jdk/pull/16325/files/5cf432fb..5f93e577 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16325&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16325&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16325/head:pull/16325 PR: https://git.openjdk.org/jdk/pull/16325 From bpb at openjdk.org Tue Oct 24 16:36:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 24 Oct 2023 16:36:53 GMT Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter [v2] In-Reply-To: References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> Message-ID: On Tue, 24 Oct 2023 08:43:09 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8318677: Adjust minBufferap verbiage > > src/java.base/share/classes/java/nio/channels/Channels.java line 427: > >> 425: * >> 426: * @implNote >> 427: * The implementation may ignore the value of {@code minBufferCap} provided. > > I think we'll need to adjust the specification of parameter too, something like "may be ignored". > > For the implNote I think it can just sat that minBufferCap is ignored. Adjusted in 5f93e5776474cc286ea32963fb55bf05cf6ce22f. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16325#discussion_r1370502955 From lmesnik at openjdk.org Tue Oct 24 17:04:41 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 24 Oct 2023 17:04:41 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6] In-Reply-To: References: Message-ID: On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth wrote: >> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc. >> >> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM. > > Leo Korinth has updated the pull request incrementally with six additional commits since the last revision: > > - static import > - copyright > - whitespace > - whitespace > - sed > - fix test/lib/jdk/test/lib/process/ProcessTools.java Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1695447658 From bpb at openjdk.org Tue Oct 24 17:32:35 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 24 Oct 2023 17:32:35 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions In-Reply-To: References: Message-ID: <7-r1I0O4r_diSpg7h_K4qWTXWwtcIka1Offba-7i-Ks=.b8f5652a-e1b9-44c5-8d3b-4f43b1b1076b@github.com> On Wed, 18 Oct 2023 16:20:55 GMT, Pavel Rappo wrote: > A `withExtension(String ext)` could handle the common cases for removing, replacing, and adding an extension. How would this work for the case of "compound extensions" such as `tar.gz` where one might want to end up with just `tar` or with `zip`, depending? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1777702279 From rriggs at openjdk.org Tue Oct 24 18:12:31 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 24 Oct 2023 18:12:31 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions In-Reply-To: <7-r1I0O4r_diSpg7h_K4qWTXWwtcIka1Offba-7i-Ks=.b8f5652a-e1b9-44c5-8d3b-4f43b1b1076b@github.com> References: <7-r1I0O4r_diSpg7h_K4qWTXWwtcIka1Offba-7i-Ks=.b8f5652a-e1b9-44c5-8d3b-4f43b1b1076b@github.com> Message-ID: <-n_YZl7qqvclBpEZ4aO9aYPpptcQLpOj778m0oBe-WE=.920dbee2-f20e-439a-a8e4-760f0dd25d46@github.com> On Tue, 24 Oct 2023 17:29:41 GMT, Brian Burkhalter wrote: > How would this work for the case of "compound extensions" such as `tar.gz` where one might want to end up with just `tar` or with `zip`, depending? I'd view that a sequence of extensions so it would take a double application of withExtension to replace both. I.e. Path path = Path.of("photos.tar.gz"); Path newP = path.withExtension("") // remove .gz; if there was no extension it would return the base .withExtension(".zip"); -> "photos.zip" // Testing for a compound extension if (path.getExtension().equals("gz") && path.withExtension("").getExtension().equals("tar")) {...} // Switching from zip to tar.gz is easier; It removes one extension and adds the string. path.withExtension("tar.gz"); // Alternatively revert to old ways; no real help in this case. path.filename().endsWith(".tar.gz"); ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1777765764 From rriggs at openjdk.org Tue Oct 24 19:42:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 24 Oct 2023 19:42:43 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6] In-Reply-To: References: Message-ID: <6qyfRp98A2DA7Q7YhscmdmokkIvVVn9HxB_XjRdM47g=.615d7a65-e109-41db-b955-31c0a934debd@github.com> On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth wrote: >> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc. >> >> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM. > > Leo Korinth has updated the pull request incrementally with six additional commits since the last revision: > > - static import > - copyright > - whitespace > - whitespace > - sed > - fix test/lib/jdk/test/lib/process/ProcessTools.java test/lib/jdk/test/lib/process/ProcessTools.java line 506: > 504: */ > 505: public static ProcessBuilder createTestJavaProcessBuilder(List command) { > 506: return createTestJavaProcessBuilder(command.toArray(String[]::new)); The javadoc shoul d describe all of the options being added to the ProcessBuilder. They were inadequated described previously and still are. The other options (seem to be from the code), test.noclasspath, java.class.path, and test.thread.factory. The description of test.thread.factory and addTestThreadFactoryArgs method seems inadequately described. test/lib/jdk/test/lib/process/ProcessTools.java line 527: > 525: * Create ProcessBuilder using the java launcher from the jdk to > 526: * be tested. > 527: * As above, should described the limited options that are added to the ProcessBuilder, the same as for `reateTestJavaProcessBuilder(...)` test/lib/jdk/test/lib/process/ProcessTools.java line 549: > 547: * Create ProcessBuilder using the java launcher from the jdk to > 548: * be tested. > 549: * As above, should described the limited options that are added to the ProcessBuilder, the same as for reateTestJavaProcessBuilder(...) test/lib/jdk/test/lib/process/ProcessTools.java line 599: > 597: */ > 598: public static OutputAnalyzer executeTestJvm(String... cmds) throws Exception { > 599: ProcessBuilder pb = createTestJavaProcessBuilder(cmds); This should also describe *all* of the options being set in the ProcessBuilder before executing the process. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370728371 PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729609 PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729925 PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370730637 From alanb at openjdk.org Tue Oct 24 19:44:35 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 24 Oct 2023 19:44:35 GMT Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter [v2] In-Reply-To: References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> Message-ID: On Tue, 24 Oct 2023 16:36:52 GMT, Brian Burkhalter wrote: >> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8318677: Adjust minBufferap verbiage I think this is okay. Given that the spec is extended to allow for the ignore case then I think a CSR will be needed. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16325#pullrequestreview-1695753249 From bpb at openjdk.org Tue Oct 24 23:25:47 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 24 Oct 2023 23:25:47 GMT Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter [v3] In-Reply-To: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> Message-ID: > Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8318677: Correct the faux pas of the previous commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16325/files - new: https://git.openjdk.org/jdk/pull/16325/files/5f93e577..60ba5c0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16325&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16325&range=01-02 Stats: 8 lines in 1 file changed: 3 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16325/head:pull/16325 PR: https://git.openjdk.org/jdk/pull/16325 From stefank at openjdk.org Wed Oct 25 07:27:32 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 25 Oct 2023 07:27:32 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com> Message-ID: On Tue, 5 Sep 2023 18:05:34 GMT, Roger Riggs wrote: >> I have created an alternative that uses enums to force the user to make a decision: https://github.com/openjdk/jdk/compare/master...lkorinth:jdk:+process_tools . Another alternative is to do the same but instead using an enum (I think it is not as good). A third alternative is to use the current pull request with a better name. >> >> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test cases. > >> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test ca > > The current API (name) is fine and fit for purpose; it does not promise or hide extra functionality under a simple name. > > There needs to be an explicit intention in the test(s) to support after the fact that arbitrary flags can be added. > @AlanBateman's proposal for naming [above](https://github.com/openjdk/jdk/pull/15452#issuecomment-1700459277) (or similar) would capture more clearly that test options are propagated to the child process. > Every test writer should be aware that additional command line options may be mixed in. > > There are many cases in which the ProcessTools APIs are not used to create child processes and do not need to be used in writing tests. They provide some convenience but also add a dependency and another API layer to work through in the case of failures. > > As far as I'm aware, there is no general guidance or design pattern outside of hotspot tests to propagate flags or use ProcessTools. Adding that as a requirement will need a different level of communication and change. @RogerRiggs You seem to know what you want w.r.t. the extra java doc comments. Could you help write those? Could we also do that as a separate RFE? I think that would make it easier to get this PR and the javadoc update through the door. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1778669353 From lkorinth at openjdk.org Wed Oct 25 08:44:29 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 25 Oct 2023 08:44:29 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7] In-Reply-To: References: Message-ID: > This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc. > > This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: fix copyright year and indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15452/files - new: https://git.openjdk.org/jdk/pull/15452/files/2f57a32d..4cc3865a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=05-06 Stats: 23 lines in 1 file changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/15452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452 PR: https://git.openjdk.org/jdk/pull/15452 From rriggs at openjdk.org Wed Oct 25 13:28:32 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 25 Oct 2023 13:28:32 GMT Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter [v3] In-Reply-To: References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> Message-ID: <0ACuC1BvhVg_63ePHjoTM4ury9etseIOVLgJvV3odOE=.19adc30d-ab35-4b83-8023-166463504943@github.com> On Tue, 24 Oct 2023 23:25:47 GMT, Brian Burkhalter wrote: >> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8318677: Correct the faux pas of the previous commit src/java.base/share/classes/java/nio/channels/Channels.java line 538: > 536: * The minimum capacity of the internal byte buffer, > 537: * or {@code -1} if an implementation-dependent > 538: * default capacity is to be used; may be ignored I'm not understanding this. The implNote says it *is* ignored, the annotation on the @param says *may*. * The minimum capacity of the internal byte buffer, * or {@code -1} if an implementation-dependent default capacity is to be used. * The minimum capacity is ignored. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16325#discussion_r1371758054 From alanb at openjdk.org Wed Oct 25 13:28:33 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 25 Oct 2023 13:28:33 GMT Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter [v3] In-Reply-To: <0ACuC1BvhVg_63ePHjoTM4ury9etseIOVLgJvV3odOE=.19adc30d-ab35-4b83-8023-166463504943@github.com> References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> <0ACuC1BvhVg_63ePHjoTM4ury9etseIOVLgJvV3odOE=.19adc30d-ab35-4b83-8023-166463504943@github.com> Message-ID: On Wed, 25 Oct 2023 13:24:05 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8318677: Correct the faux pas of the previous commit > > src/java.base/share/classes/java/nio/channels/Channels.java line 538: > >> 536: * The minimum capacity of the internal byte buffer, >> 537: * or {@code -1} if an implementation-dependent >> 538: * default capacity is to be used; may be ignored > > I'm not understanding this. The implNote says it *is* ignored, the annotation on the @param says *may*. > > > * The minimum capacity of the internal byte buffer, > * or {@code -1} if an implementation-dependent default capacity is to be used. > * The minimum capacity is ignored. > I'm not understanding this. The implNote says it _is_ ignored, the annotation on the @param says _may_. The spec allows the value to be ignored, the JDK implementation ignores the value. So it's spec vs. implementation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16325#discussion_r1371761296 From tprinzing at openjdk.org Wed Oct 25 21:43:54 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 25 Oct 2023 21:43:54 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v3] In-Reply-To: References: Message-ID: > Added jar event support to socket adapters. > > Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: changes from review: - use loopback address - fetch timeout once - formatting improvements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16251/files - new: https://git.openjdk.org/jdk/pull/16251/files/06e35acf..625fc6a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16251&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16251&range=01-02 Stats: 18 lines in 2 files changed: 8 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/16251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16251/head:pull/16251 PR: https://git.openjdk.org/jdk/pull/16251 From rriggs at openjdk.org Wed Oct 25 22:00:31 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 25 Oct 2023 22:00:31 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7] In-Reply-To: References: Message-ID: On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth wrote: >> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc. >> >> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright year and indentation Suggestions to complete the descriptions of the createXXXJavaProcessBuilder methods. test/lib/jdk/test/lib/process/ProcessTools.java line 505: > 503: * @return The ProcessBuilder instance representing the java command. > 504: */ > 505: public static ProcessBuilder createTestJavaProcessBuilder(List command) { Include the same description of other properties that are included in creating the ProcessBuilder... ``` * Unless the "test.noclasspath" property is "true" * the classpath property "java.class.path" is appended to the command line and * the environment of the ProcessBuilder is modified to remove "CLASSPATH". * If the property "test.thread.factory" is provided the command args are * updated and appended to invoke ProcessTools main() and provide the * name of the thread factory. * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value. * The remaining command args are scanned for unsupported options and * are appended to the ProcessBuilder. test/lib/jdk/test/lib/process/ProcessTools.java line 520: > 518: * @return The ProcessBuilder instance representing the java command. > 519: */ > 520: public static ProcessBuilder createTestJavaProcessBuilder(String... command) { Include the same description of other properties that are included in creating the ProcessBuilder... * Unless the "test.noclasspath" property is "true" * the classpath property "java.class.path" is appended to the command line and * the environment of the ProcessBuilder is modified to remove "CLASSPATH". * If the property "test.thread.factory" is provided the command args are * updated and appended to invoke ProcessTools main() and provide the * name of the thread factory. * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value. * The remaining command args are scanned for unsupported options and * are appended to the ProcessBuilder. test/lib/jdk/test/lib/process/ProcessTools.java line 538: > 536: * it in combination with @requires vm.flagless JTREG > 537: * anotation as to not waste energy and test resources. > 538: * Consider adding this description of what this method does. Suggestion: * Unless the "test.noclasspath" property is "true" * the classpath property "java.class.path" is appended to the command line and * the environment of the ProcessBuilder is modified to remove "CLASSPATH". * If the property "test.thread.factory" is provided the command args are * updated and appended to invoke ProcessTools main() and provide the * name of the thread factory. * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value. * The remaining command args are scanned for unsupported options and * are appended to the ProcessBuilder. test/lib/jdk/test/lib/process/ProcessTools.java line 560: > 558: * it in combination with @requires vm.flagless JTREG > 559: * anotation as to not waste energy and test resources. > 560: * Suggestion: * Unless the "test.noclasspath" property is "true" * the classpath property "java.class.path" is appended to the command line and * the environment of the ProcessBuilder is modified to remove "CLASSPATH". * If the property "test.thread.factory" is provided the command args are * updated and appended to invoke ProcessTools main() and provide the * name of the thread factory. * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value. * The remaining command args are scanned for unsupported options and * are appended to the ProcessBuilder. ------------- PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1698308785 PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364800 PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364171 PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372361862 PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372362333 From dfuchs at openjdk.org Thu Oct 26 10:36:36 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 26 Oct 2023 10:36:36 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v3] In-Reply-To: References: Message-ID: On Wed, 25 Oct 2023 21:43:54 GMT, Tim Prinzing wrote: >> Added jar event support to socket adapters. >> >> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > changes from review: > > - use loopback address > - fetch timeout once > - formatting improvements Looks good to me. I like the use of `offer` to reduce the boiler-plate code, when acquiring the event parameters doesn't cause any allocation and just return some field value. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16251#pullrequestreview-1699265942 From alanb at openjdk.org Thu Oct 26 10:39:35 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 26 Oct 2023 10:39:35 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v3] In-Reply-To: References: Message-ID: On Wed, 25 Oct 2023 21:43:54 GMT, Tim Prinzing wrote: >> Added jar event support to socket adapters. >> >> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > changes from review: > > - use loopback address > - fetch timeout once > - formatting improvements src/java.base/share/classes/sun/nio/ch/SocketInputStream.java line 2: > 1: /* > 2: * Copyright (c) 2022,2023 Oracle and/or its affiliates. All rights reserved. I think the Oracle copyright header checker will ask you to put a space after the comma. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372950705 From alanb at openjdk.org Thu Oct 26 10:44:35 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 26 Oct 2023 10:44:35 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v3] In-Reply-To: References: Message-ID: <9PEFM0H6vsuBSjolf4Mwp-8qf_wDC2gygQaa80SW-LY=.a8a11150-3695-469e-9694-96b9f002768f@github.com> On Wed, 25 Oct 2023 21:43:54 GMT, Tim Prinzing wrote: >> Added jar event support to socket adapters. >> >> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > changes from review: > > - use loopback address > - fetch timeout once > - formatting improvements src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 497: > 495: long start = SocketReadEvent.timestamp(); > 496: int nbytes = implRead(buf); > 497: SocketReadEvent.offer(start, nbytes, remoteAddress(), 0); I don't have a strong opinion on shouldCommit+emit vs. offer, both are readable at the use sites. If we go with what you have then we'll need to look into making remoteAddress a stable field. src/java.base/share/classes/sun/nio/ch/SocketInputStream.java line 83: > 81: int n = implRead(b, off, len, timeout); > 82: SocketReadEvent.offer(start, n, sc.remoteAddress(), timeout); > 83: return n; This is better, it means that the event is guaranteed to use the same timeout as the read operation. test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 75: > 73: recording.start(); > 74: > 75: ssc.socket().setReuseAddress(true); No need for setReuseAddress here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372953644 PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372954447 PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372956024 From alanb at openjdk.org Thu Oct 26 10:50:35 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 26 Oct 2023 10:50:35 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v3] In-Reply-To: References: Message-ID: On Wed, 25 Oct 2023 21:43:54 GMT, Tim Prinzing wrote: >> Added jar event support to socket adapters. >> >> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > changes from review: > > - use loopback address > - fetch timeout once > - formatting improvements test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 48: > 46: > 47: /** > 48: * @test It might be useful to have the `@bug` tag to link to JDK-8310978. test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 91: > 89: > 90: int bytesRead = is.read(bs, 0, 3); > 91: assertEquals(bytesRead, 3, "Wrong bytesRead partial buffer"); This is probably okay although in theory the read method may return 1 or 2 bytes here. Initially I thought you should be using readNBytes here but that may involve more than one read and thus disrupt the number of events expected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372962518 PR Review Comment: https://git.openjdk.org/jdk/pull/16251#discussion_r1372961460 From lkorinth at openjdk.org Thu Oct 26 15:33:38 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 26 Oct 2023 15:33:38 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7] In-Reply-To: References: Message-ID: On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth wrote: >> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc. >> >> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright year and indentation Would it be okay if we handle the new method documentation in a separate pull request? After applying your changes, I also noted that the existing description `The command line will be like: {test.jdk}/bin/java {test.vm.opts} {test.java.opts} cmds` is not only incorrect (or at least incomplete), but now also clashes with the added description. I then removed the sentence, but after I did that I also found out that similar wording exist in `executeTestJvm` and I fear that if I continue to pull strings, I will create more and more changes that you will have opinions on. Is it all right if we push what we have now, and that I create a new pull requests with these improvements in documentation that are actually not related to the changes in this pull request? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1781359450 From rriggs at openjdk.org Thu Oct 26 16:29:40 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 26 Oct 2023 16:29:40 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7] In-Reply-To: References: Message-ID: On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth wrote: >> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc. >> >> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright year and indentation ok, to correct the javadoc in a subsequent PR. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1700061972 From bpb at openjdk.org Thu Oct 26 20:43:04 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 26 Oct 2023 20:43:04 GMT Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter [v4] In-Reply-To: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> Message-ID: > Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8318677: Improve the clarity of the spec of minBufferCap in newWriter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16325/files - new: https://git.openjdk.org/jdk/pull/16325/files/60ba5c0f..a48c2ece Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16325&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16325&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16325/head:pull/16325 PR: https://git.openjdk.org/jdk/pull/16325 From rriggs at openjdk.org Thu Oct 26 20:43:04 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 26 Oct 2023 20:43:04 GMT Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter [v4] In-Reply-To: References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> Message-ID: On Thu, 26 Oct 2023 20:38:47 GMT, Brian Burkhalter wrote: >> Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8318677: Improve the clarity of the spec of minBufferCap in newWriter Thanks for the clarification. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16325#pullrequestreview-1700604502 From bpb at openjdk.org Thu Oct 26 20:47:32 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 26 Oct 2023 20:47:32 GMT Subject: RFR: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter [v2] In-Reply-To: References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> Message-ID: On Tue, 24 Oct 2023 19:42:16 GMT, Alan Bateman wrote: > I think this is okay. Given that the spec is extended to allow for the ignore case then I think a CSR will be needed. I clarified the verbiage slightly in a48c2ece4f9e8eeb5e8521a3ff4602c54a4596d7. The CSR changed identically but was not moved back to draft. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16325#issuecomment-1781869554 From lkorinth at openjdk.org Fri Oct 27 08:50:47 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 27 Oct 2023 08:50:47 GMT Subject: Integrated: 8315097: Rename createJavaProcessBuilder In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth wrote: > This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc. > > This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM. This pull request has now been integrated. Changeset: d52a995f Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/d52a995f35de26c2cc4074297a75141e4a363e1b Stats: 1574 lines in 560 files changed: 44 ins; 10 del; 1520 mod 8315097: Rename createJavaProcessBuilder Reviewed-by: lmesnik, dholmes, rriggs, stefank ------------- PR: https://git.openjdk.org/jdk/pull/15452 From lkorinth at openjdk.org Fri Oct 27 09:00:48 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 27 Oct 2023 09:00:48 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7] In-Reply-To: References: Message-ID: On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth wrote: >> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc. >> >> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright year and indentation Thanks, see: https://bugs.openjdk.org/browse/JDK-8318962 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1782552641 From bpb at openjdk.org Fri Oct 27 18:57:57 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 27 Oct 2023 18:57:57 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v3] In-Reply-To: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> Message-ID: <8_HnEiptmAz7kAiau9kJ0qVm7KDIsVE1OmWM-hg9w-Y=.378b6d68-9e1f-4148-82b3-32ca49a5366a@github.com> > Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list, Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge - 8315273: Add bug ID to test - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15525/files - new: https://git.openjdk.org/jdk/pull/15525/files/a632bd88..dd3ce6d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15525&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15525&range=01-02 Stats: 176389 lines in 4907 files changed: 85553 ins; 41171 del; 49665 mod Patch: https://git.openjdk.org/jdk/pull/15525.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15525/head:pull/15525 PR: https://git.openjdk.org/jdk/pull/15525 From tprinzing at openjdk.org Fri Oct 27 19:26:48 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Fri, 27 Oct 2023 19:26:48 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v4] In-Reply-To: References: Message-ID: > Added jfr event support to socket adapters. > > Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: various fixups: - propagate TestSocketAdaptorEvents changes to TestSocketEvents and TestSocketChannelEvents. - copyright fixups - additional test tags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16251/files - new: https://git.openjdk.org/jdk/pull/16251/files/625fc6a5..4b0daa5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16251&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16251&range=02-03 Stats: 20 lines in 5 files changed: 8 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/16251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16251/head:pull/16251 PR: https://git.openjdk.org/jdk/pull/16251 From alanb at openjdk.org Sat Oct 28 16:39:33 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 28 Oct 2023 16:39:33 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v4] In-Reply-To: References: Message-ID: <8sl8xHJhjYSGJMdnw-ual0IOa7OFrIqoFIowOULZ2t0=.99312a6d-665f-4eb8-829f-2ccad9a3d67a@github.com> On Fri, 27 Oct 2023 19:26:48 GMT, Tim Prinzing wrote: >> Added jfr event support to socket adapters. >> >> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > various fixups: > > - propagate TestSocketAdaptorEvents changes to TestSocketEvents and > TestSocketChannelEvents. > - copyright fixups > - additional test tags Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16251#pullrequestreview-1702815697 From alanb at openjdk.org Sun Oct 29 17:45:32 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 29 Oct 2023 17:45:32 GMT Subject: RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops [v4] In-Reply-To: References: Message-ID: <2p2-CaNYM3k4llWW8Hv4XjS1QtAPXVb_LO6no6YXb1Q=.056231b6-18a6-4802-8c90-69fcefafcaac@github.com> On Fri, 27 Oct 2023 19:26:48 GMT, Tim Prinzing wrote: >> Added jfr event support to socket adapters. >> >> Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > various fixups: > > - propagate TestSocketAdaptorEvents changes to TestSocketEvents and > TestSocketChannelEvents. > - copyright fixups > - additional test tags > /integrate I can sponsor but your branch is more than 2 weeks behind main line so I will need to test it in the CI first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16251#issuecomment-1784179678 From tprinzing at openjdk.org Mon Oct 30 06:07:47 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Mon, 30 Oct 2023 06:07:47 GMT Subject: Integrated: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops In-Reply-To: References: Message-ID: <5v9Y1gOvnt77LDa3Fx1Y_crAG0sUyWkVIn4nSyfu5gU=.30ba0a45-475c-434b-b58b-1dcba99b187e@github.com> On Wed, 18 Oct 2023 18:00:40 GMT, Tim Prinzing wrote: > Added jfr event support to socket adapters. > > Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java This pull request has now been integrated. Changeset: 1183b221 Author: Tim Prinzing Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/1183b221c2e15d6b6c8504ca9a71a5f2050a8c15 Stats: 218 lines in 8 files changed: 188 ins; 14 del; 16 mod 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops Reviewed-by: dfuchs, alanb ------------- PR: https://git.openjdk.org/jdk/pull/16251 From bpb at openjdk.org Mon Oct 30 18:30:44 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 30 Oct 2023 18:30:44 GMT Subject: Integrated: 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter In-Reply-To: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> References: <32MlMFhZCy0jI1KZvRDqr1wkdPpAZKbrJQD54X0IcxY=.1be7ae6a-029b-4d72-9904-3f76e52bc734@github.com> Message-ID: On Mon, 23 Oct 2023 22:03:35 GMT, Brian Burkhalter wrote: > Add an `implNote` about the `minBufferCap` parameter of the three-arg `Channels.newWriter` and slightly tweak the test. This pull request has now been integrated. Changeset: d3534b08 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/d3534b08b5691c362db987f207da7cdd9c3b4b5a Stats: 7 lines in 2 files changed: 4 ins; 1 del; 2 mod 8318677: (ch) Add implNote about minBufferCap to main variant of Channels.newWriter Reviewed-by: alanb, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/16325 From bpb at openjdk.org Mon Oct 30 21:10:33 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 30 Oct 2023 21:10:33 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter wrote: > Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. This request could be reformulated as a list of three different topics: 1. the definition of a filename extension; 2. the extraction of the filename extension from a `Path`; and 3. the manipulation of the filename extension of a `Path` (to produce another `Path`). The contention thus far is centered around the third item and I conjecture that the first two items likely have a good level of consensus. I winder therefore whether it might be better to break this proposal into two proposals, the first consisting of the the first two items in the list, and the second of the third item. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1786047732