From syan at openjdk.org Tue Sep 3 02:06:57 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 3 Sep 2024 02:06:57 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v5] In-Reply-To: References: Message-ID: > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > Test fix only, the change has been verified, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: use stat -c linux command line to determise support create time or not ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/4dcdf247..fe3fbc16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=03-04 Stats: 25 lines in 1 file changed: 20 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From syan at openjdk.org Tue Sep 3 02:17:19 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 3 Sep 2024 02:17:19 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v5] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 02:06:57 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not. >> >> Test fix only, the change has been verified, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > use stat -c linux command line to determise support create time or not On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2325477129 From alanb at openjdk.org Tue Sep 3 07:30:21 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Sep 2024 07:30:21 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v5] In-Reply-To: References: Message-ID: <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com> On Tue, 3 Sep 2024 02:06:57 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not. >> >> Test fix only, the change has been verified, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > use stat -c linux command line to determise support create time or not test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 164: > 162: String l = b.readLine(); > 163: if (l != null && l.equals("-")) { return false; } > 164: } catch(Exception e) { There are several bugs/issues with this method, did you mean to bring it back? If we are launching subprocesses in this test then it can use ProcessTools infrastructure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1741563725 From syan at openjdk.org Tue Sep 3 07:38:21 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 3 Sep 2024 07:38:21 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v5] In-Reply-To: <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com> References: <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com> Message-ID: On Tue, 3 Sep 2024 07:27:15 GMT, Alan Bateman wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> use stat -c linux command line to determise support create time or not > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 164: > >> 162: String l = b.readLine(); >> 163: if (l != null && l.equals("-")) { return false; } >> 164: } catch(Exception e) { > > There are several bugs/issues with this method, did you mean to bring it back? If we are launching subprocesses in this test then it can use ProcessTools infrastructure. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not, So I want to bring it back. Thanks for the advice, I will use `ProcessTools infrastructure` later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1741575123 From sgehwolf at openjdk.org Tue Sep 3 08:18:20 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Sep 2024 08:18:20 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v5] In-Reply-To: References: <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com> Message-ID: On Tue, 3 Sep 2024 07:35:55 GMT, SendaoYan wrote: >> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 164: >> >>> 162: String l = b.readLine(); >>> 163: if (l != null && l.equals("-")) { return false; } >>> 164: } catch(Exception e) { >> >> There are several bugs/issues with this method, did you mean to bring it back? If we are launching subprocesses in this test then it can use ProcessTools infrastructure. > > It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not, So I want to bring it back. > Thanks for the advice, I will use `ProcessTools infrastructure` later. An alternative could be to use FFM API to query the statx bufs mask the kernel returns testing for the birth time bit like the actual code does. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1741630915 From syan at openjdk.org Tue Sep 3 08:53:23 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 3 Sep 2024 08:53:23 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v5] In-Reply-To: References: <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com> Message-ID: On Tue, 3 Sep 2024 08:16:00 GMT, Severin Gehwolf wrote: >> It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not, So I want to bring it back. >> Thanks for the advice, I will use `ProcessTools infrastructure` later. > > An alternative could be to use FFM API to query the statx bufs mask the kernel returns testing for the birth time bit like the actual code does. I think this PR needed to backport to jdk21u and jdk17u in future. Maybe in jdk17u can't use`FFM API`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1741682815 From syan at openjdk.org Tue Sep 3 09:02:20 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 3 Sep 2024 09:02:20 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v5] In-Reply-To: References: <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com> Message-ID: On Tue, 3 Sep 2024 08:50:46 GMT, SendaoYan wrote: >> An alternative could be to use FFM API to query the statx bufs mask the kernel returns testing for the birth time bit like the actual code does. > > I think this PR needed to backport to jdk21u and jdk17u in future. Maybe in jdk17u can't use`FFM API`? Maybe we can use this solution https://github.com/openjdk/jdk21u/pull/282 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1741695955 From syan at openjdk.org Tue Sep 3 13:05:08 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 3 Sep 2024 13:05:08 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v6] In-Reply-To: References: Message-ID: > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not. > > Test fix only, the change has been verified, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: use jni to determine the tested file support birth time or not ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/fe3fbc16..78fbf834 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=04-05 Stats: 96 lines in 4 files changed: 71 ins; 23 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From sgehwolf at openjdk.org Tue Sep 3 15:23:25 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Sep 2024 15:23:25 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v6] In-Reply-To: References: Message-ID: <6fsXARAJ9o32I_uy9CUHtfe-POqIPkp1NugNDdRogyk=.1cebe64e-870b-46e3-b10d-1e9387aa372e@github.com> On Tue, 3 Sep 2024 13:05:08 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not. >> >> Test fix only, the change has been verified, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > use jni to determine the tested file support birth time or not Changes requested by sgehwolf (Reviewer). test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 35: > 33: void* statx_func = dlsym(RTLD_DEFAULT, "statx"); > 34: return statx_func != NULL ? JNI_TRUE : JNI_FALSE; > 35: #else This is equivalent to the previous `Linker.nativeLinker().defaultLookup().find("statx").isPresent();` so isn't enough. You'd have to pass in the path and do an actual `statx` call, look at the returned statx buffer, get the mask and look whether birth time has been filled in. See: https://github.com/openjdk/jdk/commit/c89a1c35bda9002ee687b3fa267f3ef9cba78b00 Only then it makes sense to go the jni route. Having said all that, for JDK head using FFM is preferred. Let's not consider backports just yet. ------------- PR Review: https://git.openjdk.org/jdk/pull/20687#pullrequestreview-2277769847 PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1742258338 From syan at openjdk.org Tue Sep 3 16:11:42 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 3 Sep 2024 16:11:42 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v6] In-Reply-To: <6fsXARAJ9o32I_uy9CUHtfe-POqIPkp1NugNDdRogyk=.1cebe64e-870b-46e3-b10d-1e9387aa372e@github.com> References: <6fsXARAJ9o32I_uy9CUHtfe-POqIPkp1NugNDdRogyk=.1cebe64e-870b-46e3-b10d-1e9387aa372e@github.com> Message-ID: On Tue, 3 Sep 2024 15:20:43 GMT, Severin Gehwolf wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> use jni to determine the tested file support birth time or not > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 35: > >> 33: void* statx_func = dlsym(RTLD_DEFAULT, "statx"); >> 34: return statx_func != NULL ? JNI_TRUE : JNI_FALSE; >> 35: #else > > This is equivalent to the previous `Linker.nativeLinker().defaultLookup().find("statx").isPresent();` so isn't enough. You'd have to pass in the path and do an actual `statx` call, look at the returned statx buffer, get the mask and look whether birth time has been filled in. > > See: https://github.com/openjdk/jdk/commit/c89a1c35bda9002ee687b3fa267f3ef9cba78b00 > > Only then it makes sense to go the jni route. Having said all that, for JDK head using FFM is preferred. Let's not consider backports just yet. Sorry, I already realized that the current solution is incomplete, so I do not click the previous `Resolve conversation`. I will finish the solution according your advice these days, Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1742328650 From syan at openjdk.org Tue Sep 3 16:28:22 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 3 Sep 2024 16:28:22 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v6] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 13:05:08 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not. >> >> Test fix only, the change has been verified, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > use jni to determine the tested file support birth time or not I think this PR should be set as draft status, sorry for that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2326949662 From mcimadamore at openjdk.org Wed Sep 4 20:35:47 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 4 Sep 2024 20:35:47 GMT Subject: RFR: 8339285: test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames Message-ID: Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread). To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size. A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213). This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored. To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test. Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551). ------------- Commit messages: - Use registerNatives on MappedMemoryUtils native methods - Merge branch 'master' into mapped_test_handshake - Add test Changes: https://git.openjdk.org/jdk/pull/20854/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20854&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339285 Stats: 232 lines in 9 files changed: 212 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/20854.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20854/head:pull/20854 PR: https://git.openjdk.org/jdk/pull/20854 From syan at openjdk.org Thu Sep 5 08:44:29 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 5 Sep 2024 08:44:29 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v7] In-Reply-To: References: Message-ID: <4MITwe77P1YMHk1RM_fmKUqBkegiwbFPf7T325pQpD4=.a34dab17-cd55-4fab-8dc1-5d2df05859f0@github.com> > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. > > Test fix only, the change has been verified, risk is low. > > Additional test: > > - [x] Alinux3 glibc:2.32 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == true > - [x] CentOS7 glibc:2.17 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == false SendaoYan has updated the pull request incrementally with four additional commits since the last revision: - split too long lines to short lines - use "Foreign Function & Memory API" instead of JNI - fix compile error: libCreationTimeHelper.c:24:10: fatal error: 'linux/fcntl.h' file not found on windows and macos - upload JNI solution temporary ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/78fbf834..2ed8cb68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=05-06 Stats: 138 lines in 3 files changed: 118 ins; 2 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From syan at openjdk.org Thu Sep 5 08:44:29 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 5 Sep 2024 08:44:29 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v6] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 16:26:10 GMT, SendaoYan wrote: > I think this PR should be set as draft status, sorry for that. The solution has been change to, get the result from `statx` linux syscall througt `FFM API`, to determine the testd file support birth time or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2330940218 From syan at openjdk.org Thu Sep 5 08:44:29 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 5 Sep 2024 08:44:29 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v5] In-Reply-To: References: <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com> Message-ID: On Tue, 3 Sep 2024 08:50:46 GMT, SendaoYan wrote: >> An alternative could be to use FFM API to query the statx bufs mask the kernel returns testing for the birth time bit like the actual code does. > > I think this PR needed to backport to jdk21u and jdk17u in future. Maybe in jdk17u can't use`FFM API`? The solution has been change to, get the result from `statx` linux syscall througt `FFM API`, to determine the testd file support birth time or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1745049813 From syan at openjdk.org Thu Sep 5 08:44:29 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 5 Sep 2024 08:44:29 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v6] In-Reply-To: References: <6fsXARAJ9o32I_uy9CUHtfe-POqIPkp1NugNDdRogyk=.1cebe64e-870b-46e3-b10d-1e9387aa372e@github.com> Message-ID: On Tue, 3 Sep 2024 16:08:36 GMT, SendaoYan wrote: >> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 35: >> >>> 33: void* statx_func = dlsym(RTLD_DEFAULT, "statx"); >>> 34: return statx_func != NULL ? JNI_TRUE : JNI_FALSE; >>> 35: #else >> >> This is equivalent to the previous `Linker.nativeLinker().defaultLookup().find("statx").isPresent();` so isn't enough. You'd have to pass in the path and do an actual `statx` call, look at the returned statx buffer, get the mask and look whether birth time has been filled in. >> >> See: https://github.com/openjdk/jdk/commit/c89a1c35bda9002ee687b3fa267f3ef9cba78b00 >> >> Only then it makes sense to go the jni route. Having said all that, for JDK head using FFM is preferred. Let's not consider backports just yet. > > Sorry, I already realized that the current solution is incomplete, so I do not click the previous `Resolve conversation`. I will finish the solution according your advice these days, Thanks. The solution has been change to, get the result from `statx` linux syscall througt `FFM API`, to determine the testd file support birth time or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1745050319 From alanb at openjdk.org Thu Sep 5 09:58:50 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 5 Sep 2024 09:58:50 GMT Subject: RFR: 8339285: test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames In-Reply-To: References: Message-ID: <1-PtXXBPRmvpq0jvWyEFJvOCGAiH24nSI1xqywKG2VA=.cc21539d-e6f1-4600-8b0f-909cb04f49e6@github.com> On Wed, 4 Sep 2024 15:23:51 GMT, Maurizio Cimadamore wrote: > Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread). > > To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size. > > A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213). > > This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored. > > To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test. > > Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551). src/java.base/aix/native/libnio/MappedMemoryUtils.c line 229: > 227: {"unload0", "(JJ)V", (void *)&MMU_unload0}, > 228: {"force0", "(" FD "JJ)V", (void *)&MMU_force0}, > 229: }; I did a pass over this and I think it looks okay. Do the MMU_* functions still need to be jni-exported? In any case, probably better to rename them to MemoryMemoryUtils_* to avoid anything looking at symbols and thinking they are something to do with the memory management unit :-) It looks most of the signatures for this functions are misaligned with edits. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745168389 From mcimadamore at openjdk.org Thu Sep 5 11:17:34 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 5 Sep 2024 11:17:34 GMT Subject: RFR: 8339285: Test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames [v2] In-Reply-To: References: Message-ID: > Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread). > > To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size. > > A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213). > > This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored. > > To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test. > > Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551). 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/20854/files - new: https://git.openjdk.org/jdk/pull/20854/files/5a4cd150..f02b51c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20854&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20854&range=00-01 Stats: 45 lines in 3 files changed: 0 ins; 12 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/20854.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20854/head:pull/20854 PR: https://git.openjdk.org/jdk/pull/20854 From mcimadamore at openjdk.org Thu Sep 5 11:17:34 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 5 Sep 2024 11:17:34 GMT Subject: RFR: 8339285: Test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames [v2] In-Reply-To: <1-PtXXBPRmvpq0jvWyEFJvOCGAiH24nSI1xqywKG2VA=.cc21539d-e6f1-4600-8b0f-909cb04f49e6@github.com> References: <1-PtXXBPRmvpq0jvWyEFJvOCGAiH24nSI1xqywKG2VA=.cc21539d-e6f1-4600-8b0f-909cb04f49e6@github.com> Message-ID: On Thu, 5 Sep 2024 09:55:46 GMT, Alan Bateman wrote: > Do the MMU_* functions still need to be jni-exported? I've now dropped JNIEXPORT, but kept JNICALL, as that is used to set `__stdcall` (at least on Windows). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745274541 From alanb at openjdk.org Thu Sep 5 11:31:52 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 5 Sep 2024 11:31:52 GMT Subject: RFR: 8339285: Test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames [v2] In-Reply-To: References: Message-ID: On Thu, 5 Sep 2024 11:17:34 GMT, Maurizio Cimadamore wrote: >> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread). >> >> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size. >> >> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213). >> >> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored. >> >> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test. >> >> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551). > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments test/jdk/java/foreign/TestMappedHandshake.java line 90: > 88: > 89: accessExecutor.shutdown(); > 90: assertTrue(accessExecutor.awaitTermination(MAX_EXECUTOR_WAIT_SECONDS, TimeUnit.SECONDS)); ExecutorService is an AutoCloseable to you should be able to use try-with-resources and get rid of the the shutdown+awaitTermination. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745294794 From mcimadamore at openjdk.org Thu Sep 5 11:42:51 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 5 Sep 2024 11:42:51 GMT Subject: RFR: 8339285: Test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames [v2] In-Reply-To: References: Message-ID: On Thu, 5 Sep 2024 11:29:41 GMT, Alan Bateman wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > test/jdk/java/foreign/TestMappedHandshake.java line 90: > >> 88: >> 89: accessExecutor.shutdown(); >> 90: assertTrue(accessExecutor.awaitTermination(MAX_EXECUTOR_WAIT_SECONDS, TimeUnit.SECONDS)); > > ExecutorService is an AutoCloseable to you should be able to use try-with-resources and get rid of the the shutdown+awaitTermination. The test (like also its sibling `TestHandshake`) is deliberately using `shutdown`/`awaitTermination` to make sure the test finished in a reasonable amount of time (and generate correct assertion failures if it doesn't). This was mostly added to have better debugging at a time when `TestHandshake` was failing spuriously, so I'd prefer to leave it as is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745307197 From syan at openjdk.org Thu Sep 5 12:16:52 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 5 Sep 2024 12:16:52 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v7] In-Reply-To: <4MITwe77P1YMHk1RM_fmKUqBkegiwbFPf7T325pQpD4=.a34dab17-cd55-4fab-8dc1-5d2df05859f0@github.com> References: <4MITwe77P1YMHk1RM_fmKUqBkegiwbFPf7T325pQpD4=.a34dab17-cd55-4fab-8dc1-5d2df05859f0@github.com> Message-ID: On Thu, 5 Sep 2024 08:44:29 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. >> >> Test fix only, the change has been verified, risk is low. >> >> Additional test: >> >> - [x] Alinux3 glibc:2.32 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == true >> - [x] CentOS7 docker container glibc:2.17 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == false > > SendaoYan has updated the pull request incrementally with four additional commits since the last revision: > > - split too long lines to short lines > - use "Foreign Function & Memory API" instead of JNI > - fix compile error: libCreationTimeHelper.c:24:10: fatal error: 'linux/fcntl.h' file not found on windows and macos > - upload JNI solution temporary Sorry, build fails on macos and windows, I will fix it right now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2331365259 From syan at openjdk.org Thu Sep 5 12:28:37 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 5 Sep 2024 12:28:37 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v8] In-Reply-To: References: Message-ID: > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. > > Test fix only, the change has been verified, risk is low. > > Additional test: > > - [x] Alinux3 glibc:2.32 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == true > - [x] CentOS7 docker container glibc:2.17 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == false SendaoYan has updated the pull request incrementally with one additional commit since the last revision: fix compile error: libCreationTimeHelper.c:96:8: error: unknown type name bool ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/2ed8cb68..35290e8c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=06-07 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From alanb at openjdk.org Thu Sep 5 14:25:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 5 Sep 2024 14:25:54 GMT Subject: RFR: 8339285: Test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames [v2] In-Reply-To: References: Message-ID: On Thu, 5 Sep 2024 11:17:34 GMT, Maurizio Cimadamore wrote: >> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread). >> >> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size. >> >> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213). >> >> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored. >> >> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test. >> >> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551). > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20854#pullrequestreview-2283229031 From syan at openjdk.org Thu Sep 5 15:24:28 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 5 Sep 2024 15:24:28 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v9] In-Reply-To: References: Message-ID: > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. > > Test fix only, the change has been verified, risk is low. > > Additional test: > > - [x] Alinux3 glibc:2.32 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == true > - [x] CentOS7 docker container glibc:2.17 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == false SendaoYan has updated the pull request incrementally with one additional commit since the last revision: fix compile error: libCreationTimeHelper.c:125:12: error: use of undeclared identifier JNI_FALSE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/35290e8c..c364944c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From mcimadamore at openjdk.org Thu Sep 5 18:14:00 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 5 Sep 2024 18:14:00 GMT Subject: Integrated: 8339285: Test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 15:23:51 GMT, Maurizio Cimadamore wrote: > Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread). > > To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size. > > A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213). > > This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored. > > To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test. > > Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551). This pull request has now been integrated. Changeset: 9e1af8cc Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk/commit/9e1af8cc7cc9f63453097bd35eb3cf29f945d765 Stats: 253 lines in 9 files changed: 212 ins; 12 del; 29 mod 8339285: Test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/20854 From bpb at openjdk.org Thu Sep 5 23:18:51 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 5 Sep 2024 23:18:51 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v9] In-Reply-To: References: Message-ID: <-VOeZppxUJ5yR19WQrDDwn9aIc4jIe-Qkhx6EgHz3q4=.c5b46358-21f5-4016-920a-088908dbb3e5@github.com> On Thu, 5 Sep 2024 15:24:28 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. >> >> Test fix only, the change has been verified, risk is low. >> >> Additional test: >> >> - [x] Alinux3 glibc:2.32 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == true >> - [x] CentOS7 docker container glibc:2.17 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == false > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > fix compile error: libCreationTimeHelper.c:125:12: error: use of undeclared identifier JNI_FALSE Line 84 of the test: "birth time not support for: " should be changed to "birth time not supported for: ". ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2332861463 From syan at openjdk.org Fri Sep 6 01:11:31 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 6 Sep 2024 01:11:31 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v10] In-Reply-To: References: Message-ID: > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. > > Test fix only, the change has been verified, risk is low. > > Additional test: > > - [x] Alinux3 glibc:2.32 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == true > - [x] CentOS7 docker container glibc:2.17 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == false SendaoYan has updated the pull request incrementally with one additional commit since the last revision: fix typo support to supported ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/c364944c..a805b6fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From syan at openjdk.org Fri Sep 6 01:11:31 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 6 Sep 2024 01:11:31 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v9] In-Reply-To: <-VOeZppxUJ5yR19WQrDDwn9aIc4jIe-Qkhx6EgHz3q4=.c5b46358-21f5-4016-920a-088908dbb3e5@github.com> References: <-VOeZppxUJ5yR19WQrDDwn9aIc4jIe-Qkhx6EgHz3q4=.c5b46358-21f5-4016-920a-088908dbb3e5@github.com> Message-ID: On Thu, 5 Sep 2024 23:16:17 GMT, Brian Burkhalter wrote: > birth time not supported for: The typo issue has been fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2332987684 From sgehwolf at openjdk.org Fri Sep 6 09:22:54 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 6 Sep 2024 09:22:54 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v10] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 01:11:31 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. >> >> Test fix only, the change has been verified, risk is low. >> >> Additional test: >> >> - [x] Alinux3 glibc:2.32 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == true >> - [x] CentOS7 docker container glibc:2.17 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == false > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > fix typo support to supported test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 83: > 81: System.out.println("creationTime.toMillis() == " + creationTime.toMillis()); > 82: // If the file system doesn't support birth time, then skip this test > 83: if (creationTime.toMillis() == 0) { Is this still useful? After https://bugs.openjdk.org/browse/JDK-8338696 we'd never get the epoch (`0`). If birth time is not supported, the last modified time is being returned. I think this can go and the `SkippedException` branch removed as well. test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTimeHelper.java line 51: > 49: return (boolean)methodHandle.invokeExact(s); > 50: } > 51: } We should only do the downcall if we know `statx` is available. I.e. return `false` early when `!abi.defaultLookup().find("statx").isPresent()` test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 30: > 28: #define true 1 > 29: #define false 0 > 30: #endif Do we really need this? Since https://openjdk.org/jeps/347 test libraries should be compiled with `--std=c11`. test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 46: > 44: #ifndef _GNU_SOURCE > 45: #define _GNU_SOURCE > 46: #endif Why is this needed? test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 121: > 119: return false; > 120: } > 121: if (stx.stx_mask & STATX_BTIME) `if (stx.stx_mask & STAX_BTIME) != 0)` please. Also, please add a comment mentioning that "on some systems where `statx` is available birth time might still not be supported as it's file system specific. The only reliable way to check for support is looking at the filled in STATX_BTIME bit in the returned statx buffer mask." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746798514 PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746745709 PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746761279 PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746779743 PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746775412 From syan at openjdk.org Fri Sep 6 09:55:53 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 6 Sep 2024 09:55:53 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v10] In-Reply-To: References: Message-ID: <61e88pfjoOykSL-DKVlNToSbQoEsck7gHbudZxusgwY=.2155b751-434b-4754-81c1-157075bbb90e@github.com> On Fri, 6 Sep 2024 09:03:13 GMT, Severin Gehwolf wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo support to supported > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 30: > >> 28: #define true 1 >> 29: #define false 0 >> 30: #endif > > Do we really need this? Since https://openjdk.org/jeps/347 test libraries should be compiled with `--std=c11`. I am not quite sure, I copied these codes from `src/java.base/unix/native/libjsig/jsig.c`. I will check it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746859383 From syan at openjdk.org Fri Sep 6 13:16:09 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 6 Sep 2024 13:16:09 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v11] In-Reply-To: References: Message-ID: <-5ZwEEoOHmM2A-MSoYizy4z9OIZdNXFEv3UIbOe2AJ0=.ac0e104e-3106-4f85-aa7b-70ccf54ff8e4@github.com> > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. > > Test fix only, the change has been verified, risk is low. > > Additional test: > > - [x] Alinux3 glibc:2.32 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == true > - [x] CentOS7 docker container glibc:2.17 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == false SendaoYan has updated the pull request incrementally with one additional commit since the last revision: delete "#define _GNU_SOURCE" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/a805b6fd..c8e22c10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=09-10 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From syan at openjdk.org Fri Sep 6 13:16:10 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 6 Sep 2024 13:16:10 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v10] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 09:08:09 GMT, Severin Gehwolf wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo support to supported > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 46: > >> 44: #ifndef _GNU_SOURCE >> 45: #define _GNU_SOURCE >> 46: #endif > > Why is this needed? That seems not needed indeed. I will delete that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1747106294 From syan at openjdk.org Sat Sep 7 02:34:45 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 7 Sep 2024 02:34:45 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v12] In-Reply-To: References: Message-ID: > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. > > Test fix only, the change has been verified, risk is low. > > Additional test: > > - [x] Alinux3 glibc:2.32 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == true > - [x] CentOS7 docker container glibc:2.17 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == false SendaoYan has updated the pull request incrementally with one additional commit since the last revision: return false early if statx syscall is not available ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/c8e22c10..be64c32a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=10-11 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From syan at openjdk.org Sat Sep 7 02:34:45 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 7 Sep 2024 02:34:45 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v10] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 08:56:00 GMT, Severin Gehwolf wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo support to supported > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTimeHelper.java line 51: > >> 49: return (boolean)methodHandle.invokeExact(s); >> 50: } >> 51: } > > We should only do the downcall if we know `statx` is available. I.e. return `false` early when `!abi.defaultLookup().find("statx").isPresent()` Okey, code `return false early if statx syscall is not available` has been added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1747872673 From syan at openjdk.org Sat Sep 7 02:53:50 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 7 Sep 2024 02:53:50 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v13] In-Reply-To: References: Message-ID: <9IHLho18KfdtXpQwjFBA-xUvDeFaLLnsqdrqIGpatvA=.805c8739-609d-4f1f-90c2-520dcb0e0ca1@github.com> > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. > > Test fix only, the change has been verified, risk is low. > > Additional test: > > - [x] Alinux3 glibc:2.32 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == true > - [x] CentOS7 docker container glibc:2.17 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == false SendaoYan has updated the pull request incrementally with one additional commit since the last revision: STATX_BTIME return statx buffer mask convert to boolean explicitly, and add comment to explain why get STATX_BTIME bit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/be64c32a..1ca8dd02 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=11-12 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From syan at openjdk.org Sat Sep 7 02:53:50 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 7 Sep 2024 02:53:50 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v10] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 09:07:10 GMT, Severin Gehwolf wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo support to supported > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 121: > >> 119: return false; >> 120: } >> 121: if (stx.stx_mask & STATX_BTIME) > > `if (stx.stx_mask & STAX_BTIME) != 0)` please. Also, please add a comment mentioning that "on some systems where `statx` is available birth time might still not be supported as it's file system specific. The only reliable way to check for support is looking at the filled in STATX_BTIME bit in the returned statx buffer mask." Thanks for your patient code review. `STATX_BTIME` return statx buffer mask convert to boolean explicitly, and add comment to explain why get `STATX_BTIME` bit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1747877454 From syan at openjdk.org Sat Sep 7 03:08:39 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 7 Sep 2024 03:08:39 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v14] In-Reply-To: References: Message-ID: > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. > > Test fix only, the change has been verified, risk is low. > > Additional test: > > - [x] Alinux3 glibc:2.32 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == true > - [x] CentOS7 docker container glibc:2.17 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == false SendaoYan has updated the pull request incrementally with one additional commit since the last revision: After JDK-JDK-8338696, the file birth time never get the epoch (0), so delete the SkippedException for epoch (0) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/1ca8dd02..a931938a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=12-13 Stats: 10 lines in 1 file changed: 1 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From syan at openjdk.org Sat Sep 7 03:08:39 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 7 Sep 2024 03:08:39 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v10] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 09:19:25 GMT, Severin Gehwolf wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo support to supported > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 83: > >> 81: System.out.println("creationTime.toMillis() == " + creationTime.toMillis()); >> 82: // If the file system doesn't support birth time, then skip this test >> 83: if (creationTime.toMillis() == 0) { > > Is this still useful? After https://bugs.openjdk.org/browse/JDK-8338696 we'd never get the epoch (`0`). If birth time is not supported, the last modified time is being returned. I think this can go and the `SkippedException` branch removed as well. Thanks for your correction, the `SkippedException` for epoch (0) has been deleted. > test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 30: > >> 28: #define true 1 >> 29: #define false 0 >> 30: #endif > > Do we really need this? Since https://openjdk.org/jeps/347 test libraries should be compiled with `--std=c11`. I think I need some time to study that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1747880627 PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1747881022 From syan at openjdk.org Mon Sep 9 02:30:09 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 9 Sep 2024 02:30:09 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v10] In-Reply-To: References: Message-ID: On Sat, 7 Sep 2024 03:04:46 GMT, SendaoYan wrote: >> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 30: >> >>> 28: #define true 1 >>> 29: #define false 0 >>> 30: #endif >> >> Do we really need this? Since https://openjdk.org/jeps/347 test libraries should be compiled with `--std=c11`. > > I think I need some time to study that. I found other tests such as `test/jdk/java/foreign/libIntrinsics.c` only `#include ` to use bool type. So I think these codes can change to only `#include `. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1749476268 From syan at openjdk.org Mon Sep 9 02:35:38 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 9 Sep 2024 02:35:38 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v15] In-Reply-To: References: Message-ID: > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. > > Test fix only, the change has been verified, risk is low. > > Additional test: > > - [x] Alinux3 glibc:2.32 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == true > - [x] CentOS7 docker container glibc:2.17 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == false SendaoYan has updated the pull request incrementally with one additional commit since the last revision: After JEP 347, we can use bool type only "#include " ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/a931938a..66da6f72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=13-14 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From sgehwolf at openjdk.org Mon Sep 9 08:36:14 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 9 Sep 2024 08:36:14 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v15] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 02:35:38 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. >> >> Test fix only, the change has been verified, risk is low. >> >> Additional test: >> >> - [x] Alinux3 glibc:2.32 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == true >> - [x] CentOS7 docker container glibc:2.17 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == false > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > After JEP 347, we can use bool type only "#include " Seems mostly fine now. test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTimeHelper.java line 45: > 43: > 44: // Helper so as to determine 'statx' support on the runtime system > 45: // static boolean linuxIsCreationTimeSupported(String file); This comment is a bit misleading. Suggestion: // Helper so as to determine birth time support on Linux. // Support is determined in a two-step process: // 1. Determine if `statx` system call is available. If available proceed, otherwise // return false. // 2. Perform an actual `statx` call on the given file and check for birth time support // in the mask returned from the call. This is needed, since some file systems, like // nfs, don't support birth time even though the `statx` system call is available. test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTimeHelper.java line 48: > 46: static boolean linuxIsCreationTimeSupported(String file) throws Throwable { > 47: if (!abi.defaultLookup().find("statx").isPresent()) > 48: return false; I personally prefer using `if (...) { /* do something */ }` (add curly brackets). test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 91: > 89: struct my_statx stx; > 90: int ret, atflag = AT_SYMLINK_NOFOLLOW; > 91: memset(&stx, 0xbf, sizeof(stx)); Why `0xbf`? How about `struct my_statx stx = {0}`? ------------- PR Review: https://git.openjdk.org/jdk/pull/20687#pullrequestreview-2289152795 PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1749783056 PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1749785765 PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1749813293 From alanb at openjdk.org Mon Sep 9 09:27:05 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 9 Sep 2024 09:27:05 GMT Subject: RFR: 8338858: Replace undocumented APIs with documented APIs in the OpenJDK In-Reply-To: References: Message-ID: <-1OB44IWKlMG05Zn4-VTtqbbOhxKGilDbNaAui8qrbc=.aa679d75-fce6-4006-8c23-ba973d893225@github.com> On Thu, 22 Aug 2024 18:18:57 GMT, Dhamoder Nalla wrote: > The `wepoll` code has been ported from opensource repo [`wepoll`](https://github.com/piscisaureus/wepoll) to OpenJDK in PR [pull/3816](https://github.com/openjdk/jdk/pull/3816), which incorporated undocumented Windows APIs (NtCreateKeyedEvent, NtReleaseKeyedEvent, NtWaitForKeyedEvent). > > This PR aims to replace these undocumented APIs with documented synchronization APIs. > > Test Performed: > 1. All 12 tests in wepoll repo passed > test-auto-drop-on-close PASS > test-connect-fail-events PASS > test-connect-success-events PASS > test-ctl-fuzz PASS > test-error PASS > test-leak-1 PASS > test-mixed-socket-types PASS > test-multi-poll PASS > test-oneshot-and-hangup PASS > test-reflock PASS > test-tree PASS > test-udp-pings PASS > DONE - 12 PASSED, 0 FAILED > > 2. No new failure in JTreg test > 3. Micro bench results: similar performance score before and after the changes > > without change in this PR: > > ![image](https://github.com/user-attachments/assets/c784d00e-3f0a-483d-b60a-c7a46aba885c) > > With the change in this PR: > > ![image](https://github.com/user-attachments/assets/5e6a68bc-48ae-475f-891e-395941068f6e) Can you confirm that you've run jdk tier2 with these changes? @djelinski Would you have cycles to look at this? Ideally the changes would go upstream and/or Microsoft would contribute resources to that project. From a quick scan, the changes aren't too bad although there are some needless fixes to comment typos. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20682#issuecomment-2337589854 PR Comment: https://git.openjdk.org/jdk/pull/20682#issuecomment-2337595430 From syan at openjdk.org Mon Sep 9 12:02:25 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 9 Sep 2024 12:02:25 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v16] In-Reply-To: References: Message-ID: > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. > > Test fix only, the change has been verified, risk is low. > > Additional test: > > - [x] Alinux3 glibc:2.32 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == true > - [x] CentOS7 docker container glibc:2.17 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == false SendaoYan has updated the pull request incrementally with one additional commit since the last revision: 1. add curly brackets in function linuxIsCreationTimeSupported; 2. complement comment for function linuxIsCreationTimeSupported ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/66da6f72..2db0988d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=14-15 Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From syan at openjdk.org Mon Sep 9 12:02:26 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 9 Sep 2024 12:02:26 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v15] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 08:13:41 GMT, Severin Gehwolf wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> After JEP 347, we can use bool type only "#include " > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTimeHelper.java line 48: > >> 46: static boolean linuxIsCreationTimeSupported(String file) throws Throwable { >> 47: if (!abi.defaultLookup().find("statx").isPresent()) >> 48: return false; > > I personally prefer using `if (...) { /* do something */ }` (add curly brackets). Thanks for your patient code review again. 1. curly brackets in function linuxIsCreationTimeSupported has been added; 2. comment for function linuxIsCreationTimeSupported has been complemented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1750127468 From syan at openjdk.org Mon Sep 9 12:42:23 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 9 Sep 2024 12:42:23 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v17] In-Reply-To: References: Message-ID: > Hi all, > On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). > > Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. > > On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. > > Test fix only, the change has been verified, risk is low. > > Additional test: > > - [x] Alinux3 glibc:2.32 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == true > - [x] CentOS7 docker container glibc:2.17 > 1. /tmp/file supportsCreationTimeRead == false > 2. ./file supportsCreationTimeRead == false SendaoYan has updated the pull request incrementally with one additional commit since the last revision: initail struct stx var to zero ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20687/files - new: https://git.openjdk.org/jdk/pull/20687/files/2db0988d..7a7916f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=15-16 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687 PR: https://git.openjdk.org/jdk/pull/20687 From syan at openjdk.org Mon Sep 9 12:42:23 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 9 Sep 2024 12:42:23 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v16] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:02:25 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. >> >> Test fix only, the change has been verified, risk is low. >> >> Additional test: >> >> - [x] Alinux3 glibc:2.32 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == true >> - [x] CentOS7 docker container glibc:2.17 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == false > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > 1. add curly brackets in function linuxIsCreationTimeSupported; 2. complement comment for function linuxIsCreationTimeSupported Because this test invoke native libary, so mark this test as `/native`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2338015273 From syan at openjdk.org Mon Sep 9 12:42:24 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 9 Sep 2024 12:42:24 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v15] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 08:30:28 GMT, Severin Gehwolf wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> After JEP 347, we can use bool type only "#include " > > test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 91: > >> 89: struct my_statx stx; >> 90: int ret, atflag = AT_SYMLINK_NOFOLLOW; >> 91: memset(&stx, 0xbf, sizeof(stx)); > > Why `0xbf`? > > How about `struct my_statx stx = {0}`? I implement this code imitate from [test-statx.c](https://github.com/torvalds/linux/blob/master/samples/vfs/test-statx.c#L251), and I'm not quite sure why the testcase initial struct var stx to `0xbf`. I think initial to zero will be Okey also. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1750177644 From mcimadamore at openjdk.org Mon Sep 9 13:02:15 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 9 Sep 2024 13:02:15 GMT Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames Message-ID: The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously. While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context. To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism. Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jdk/pull/20914/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20914&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339686 Stats: 104 lines in 7 files changed: 48 ins; 30 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/20914.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20914/head:pull/20914 PR: https://git.openjdk.org/jdk/pull/20914 From mcimadamore at openjdk.org Mon Sep 9 13:02:15 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 9 Sep 2024 13:02:15 GMT Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore wrote: > The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously. > While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context. > > To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism. > > Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context. src/java.base/share/classes/jdk/internal/access/foreign/MappedMemoryUtilsProxy.java line 9: > 7: * This allows to avoid pesky initialization issues in the middle of memory mapped scoped methods. > 8: */ > 9: public interface MappedMemoryUtilsProxy { We should probably try to consolidate this and `UmapperProxy` - I think it can be done, but it requires deeper surgery than I was willing to do in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750215021 From mcimadamore at openjdk.org Mon Sep 9 13:28:12 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 9 Sep 2024 13:28:12 GMT Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore wrote: > The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously. > While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context. > > To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism. > > Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context. src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template line 255: > 253: session.checkValidStateRaw(); > 254: } > 255: return mappedUtils.isLoaded(address, isSync, size); this method (and other related methods) now only performs a straight call into `MappedMemoryUtilsProxy`. Static initializers and JNI resolution has already run, so we should no longer use too much stack. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750259314 From jvernee at openjdk.org Mon Sep 9 13:35:08 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 9 Sep 2024 13:35:08 GMT Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore wrote: > The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously. > While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context. > > To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism. > > Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context. Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20914#pullrequestreview-2289932524 From sgehwolf at openjdk.org Mon Sep 9 13:47:09 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 9 Sep 2024 13:47:09 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v17] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:42:23 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. >> >> Test fix only, the change has been verified, risk is low. >> >> Additional test: >> >> - [x] Alinux3 glibc:2.32 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == true >> - [x] CentOS7 docker container glibc:2.17 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == false > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > initail struct stx var to zero This looks good to me. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20687#pullrequestreview-2289970806 From mdoerr at openjdk.org Mon Sep 9 14:26:04 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 9 Sep 2024 14:26:04 GMT Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore wrote: > The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously. > While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context. > > To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism. > > Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context. This resolves one of the issues on AIX, but [JDK-8339780](https://bugs.openjdk.org/browse/JDK-8339780) is still a problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20914#issuecomment-2338269170 From mcimadamore at openjdk.org Mon Sep 9 15:33:45 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 9 Sep 2024 15:33:45 GMT Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames [v2] In-Reply-To: <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com> References: <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com> Message-ID: <2AyUfXadm-G7KHrhes_F_kIvYd6lu8lDH-mtPokog7c=.f4559d51-8ae7-4077-a1b1-8f48202fc6db@github.com> On Mon, 9 Sep 2024 15:30:47 GMT, Maurizio Cimadamore wrote: >> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously. >> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context. >> >> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism. >> >> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Drop spurious change src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 128: > 126: static { > 127: registerNatives(); > 128: isLoaded0(0, 0, 0); This spurious line was added for debugging reasons in a previous PR - it should have been removed. Doing it now. This is probably the cause of https://bugs.openjdk.org/browse/JDK-8339780 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750481339 From mcimadamore at openjdk.org Mon Sep 9 15:33:44 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 9 Sep 2024 15:33:44 GMT Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames [v2] In-Reply-To: References: Message-ID: <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com> > The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously. > While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context. > > To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism. > > Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Drop spurious change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20914/files - new: https://git.openjdk.org/jdk/pull/20914/files/32389c43..4053014e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20914&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20914&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20914.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20914/head:pull/20914 PR: https://git.openjdk.org/jdk/pull/20914 From mdoerr at openjdk.org Mon Sep 9 15:41:06 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 9 Sep 2024 15:41:06 GMT Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames [v2] In-Reply-To: <2AyUfXadm-G7KHrhes_F_kIvYd6lu8lDH-mtPokog7c=.f4559d51-8ae7-4077-a1b1-8f48202fc6db@github.com> References: <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com> <2AyUfXadm-G7KHrhes_F_kIvYd6lu8lDH-mtPokog7c=.f4559d51-8ae7-4077-a1b1-8f48202fc6db@github.com> Message-ID: On Mon, 9 Sep 2024 15:30:47 GMT, Maurizio Cimadamore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop spurious change > > src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 128: > >> 126: static { >> 127: registerNatives(); >> 128: isLoaded0(0, 0, 0); > > This spurious line was added for debugging reasons in a previous PR - it should have been removed. Doing it now. This is probably the cause of https://bugs.openjdk.org/browse/JDK-8339780 Yes. Thanks for fixing it! Maybe you can add that issue to this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750492934 From djelinski at openjdk.org Mon Sep 9 16:39:05 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 9 Sep 2024 16:39:05 GMT Subject: RFR: 8338858: Replace undocumented APIs with documented APIs in the OpenJDK In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 18:18:57 GMT, Dhamoder Nalla wrote: > The `wepoll` code has been ported from opensource repo [`wepoll`](https://github.com/piscisaureus/wepoll) to OpenJDK in PR [pull/3816](https://github.com/openjdk/jdk/pull/3816), which incorporated undocumented Windows APIs (NtCreateKeyedEvent, NtReleaseKeyedEvent, NtWaitForKeyedEvent). > > This PR aims to replace these undocumented APIs with documented synchronization APIs. > > Test Performed: > 1. All 12 tests in wepoll repo passed > test-auto-drop-on-close PASS > test-connect-fail-events PASS > test-connect-success-events PASS > test-ctl-fuzz PASS > test-error PASS > test-leak-1 PASS > test-mixed-socket-types PASS > test-multi-poll PASS > test-oneshot-and-hangup PASS > test-reflock PASS > test-tree PASS > test-udp-pings PASS > DONE - 12 PASSED, 0 FAILED > > 2. No new failure in JTreg test > 3. Micro bench results: similar performance score before and after the changes > > without change in this PR: > > ![image](https://github.com/user-attachments/assets/c784d00e-3f0a-483d-b60a-c7a46aba885c) > > With the change in this PR: > > ![image](https://github.com/user-attachments/assets/5e6a68bc-48ae-475f-891e-395941068f6e) I understand that this is a like-for-like replacement, where `reflock__signal_event` waits for another thread to call `reflock__await_event`, because that's what `NtReleaseKeyedEvent` did, even if that is not necessary from the perspective of the calling code. It looks OK, but it doesn't make the code easier to follow. I think if we're going to touch this code, we should make it more readable than the original. We could replace the whole reflock structure with SRW locks; `reflock_ref` is semantically equivalent to `AcquireSRWLockShared`, `reflock_unref` is equivalent to `ReleaseSRWLockShared`, and `reflock_unref_and_destroy` is equivalent to `ReleaseSRWLockShared` followed by `AcquireSRWLockExclusive`. Also, I'd very much like to avoid forking wepoll here. We keep our own copy to simplify the build system, but we don't want to maintain our own fork. @dhanalla if the https://github.com/piscisaureus/wepoll/pull/37 request is not accepted, do you plan to maintain a fork of wepoll? Or is wepoll officially dead? Finally, this PR claims to replace the undocumented APIs, but does nothing about the usage of AFD. Is there a plan to remove the AFD too? ------------- PR Review: https://git.openjdk.org/jdk/pull/20682#pullrequestreview-2290417466 From alanb at openjdk.org Mon Sep 9 18:52:05 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 9 Sep 2024 18:52:05 GMT Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames [v2] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:59:15 GMT, Maurizio Cimadamore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop spurious change > > src/java.base/share/classes/jdk/internal/access/foreign/MappedMemoryUtilsProxy.java line 9: > >> 7: * This allows to avoid pesky initialization issues in the middle of memory mapped scoped methods. >> 8: */ >> 9: public interface MappedMemoryUtilsProxy { > > We should probably try to consolidate this and `UmapperProxy` - I think it can be done, but it requires deeper surgery than I was willing to do in this PR. Although this proxy class may be temporarily, I'll think you'll need to put a copyright header on it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750760987 From mcimadamore at openjdk.org Mon Sep 9 21:11:32 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 9 Sep 2024 21:11:32 GMT Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames [v3] In-Reply-To: References: Message-ID: > The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously. > While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context. > > To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism. > > Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20914/files - new: https://git.openjdk.org/jdk/pull/20914/files/4053014e..80b61d15 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20914&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20914&range=01-02 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20914.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20914/head:pull/20914 PR: https://git.openjdk.org/jdk/pull/20914 From bpb at openjdk.org Mon Sep 9 21:37:08 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Sep 2024 21:37:08 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c continue; ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2339193692 From dhanalla at openjdk.org Mon Sep 9 21:45:07 2024 From: dhanalla at openjdk.org (Dhamoder Nalla) Date: Mon, 9 Sep 2024 21:45:07 GMT Subject: RFR: 8338858: Replace undocumented APIs with documented APIs in the OpenJDK In-Reply-To: <-1OB44IWKlMG05Zn4-VTtqbbOhxKGilDbNaAui8qrbc=.aa679d75-fce6-4006-8c23-ba973d893225@github.com> References: <-1OB44IWKlMG05Zn4-VTtqbbOhxKGilDbNaAui8qrbc=.aa679d75-fce6-4006-8c23-ba973d893225@github.com> Message-ID: On Mon, 9 Sep 2024 09:21:59 GMT, Alan Bateman wrote: > Can you confirm that you've run jdk tier2 with these changes? @AlanBateman, I have run both Tier 1 and Tier 2 tests and can confirm that there are no new failures related to this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20682#issuecomment-2339206609 From jpai at openjdk.org Tue Sep 10 09:51:29 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 10 Sep 2024 09:51:29 GMT Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests Message-ID: Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment? As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851. There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that. ------------- Commit messages: - 8339834: Replace usages of -mx and -ms in some tests Changes: https://git.openjdk.org/jdk/pull/20930/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20930&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339834 Stats: 15 lines in 8 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/20930.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20930/head:pull/20930 PR: https://git.openjdk.org/jdk/pull/20930 From jpai at openjdk.org Tue Sep 10 11:10:38 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 10 Sep 2024 11:10:38 GMT Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2] In-Reply-To: References: Message-ID: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com> > Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment? > > As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851. > > There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: update JImageToolTest too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20930/files - new: https://git.openjdk.org/jdk/pull/20930/files/51d15461..8214fdb5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20930&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20930&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20930.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20930/head:pull/20930 PR: https://git.openjdk.org/jdk/pull/20930 From dholmes at openjdk.org Tue Sep 10 11:10:38 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Sep 2024 11:10:38 GMT Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2] In-Reply-To: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com> References: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com> Message-ID: On Tue, 10 Sep 2024 11:07:30 GMT, Jaikiran Pai wrote: >> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851. >> >> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > update JImageToolTest too LGTM! Thanks for cleaning this up. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2292111663 From djelinski at openjdk.org Tue Sep 10 11:36:10 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 10 Sep 2024 11:36:10 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c make/modules/java.base/Lib.gmk line 48: > 46: OPTIMIZATION := LOW, \ > 47: EXTRA_HEADER_DIRS := \ > 48: libjava/nio/ch, \ This appears to be unneeded make/modules/java.base/Lib.gmk line 81: > 79: libjava/nio/ch \ > 80: libnio/ch \ > 81: libnio/fs \ libnio/fs is gone on all platforms other than aix; is this still necessary? make/modules/java.base/lib/CoreLibraries.gmk line 71: > 69: -framework Foundation \ > 70: -framework SystemConfiguration, \ > 71: LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \ Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms. src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575: > 573: * Used to trigger loading of native libraries > 574: */ > 575: public static void load() { } do we still need this method? src/java.base/unix/classes/sun/nio/ch/NativeThread.java line 2: > 1: /* > 2: * Copyright (c) 2002, 2024, Oracle and/or its affiliates. All rights reserved. No changes in this file src/java.base/unix/native/libnio/ch/NIOUtil.c line 34: > 32: #include "jvm.h" > 33: #include "jlong.h" > 34: #include "sun_nio_ch_IOUtil.h" should this be NIOUtil? src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097: > 1095: > 1096: static { > 1097: jdk.internal.loader.BootLoader.loadLibrary("net"); ...do we still need net here? src/java.base/windows/native/libnio/ch/NIOUtil.c line 41: > 39: > 40: JNIEXPORT jboolean JNICALL > 41: Java_sun_security_provider_NativeSeedGenerator_nativeGenerateSeed unused ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751645238 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751648219 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751651925 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751744295 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751746774 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751766398 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751770939 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751774903 From ihse at openjdk.org Tue Sep 10 13:33:09 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 10 Sep 2024 13:33:09 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 09:56:26 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c > > make/modules/java.base/Lib.gmk line 81: > >> 79: libjava/nio/ch \ >> 80: libnio/ch \ >> 81: libnio/fs \ > > libnio/fs is gone on all platforms other than aix; is this still necessary? We can't add extra header dirs on a per-platform basis, so if it is needed for AIX it will need to remain here. Otoh, the only "cost" is an additional `-I ` argument to the compiler, so it's not too bad. But if we can remove it, we should, of course. > make/modules/java.base/lib/CoreLibraries.gmk line 71: > >> 69: -framework Foundation \ >> 70: -framework SystemConfiguration, \ >> 71: LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \ > > Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms. I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751967809 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751975461 From djelinski at openjdk.org Tue Sep 10 15:18:09 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 10 Sep 2024 15:18:09 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 13:30:05 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.base/lib/CoreLibraries.gmk line 71: >> >>> 69: -framework Foundation \ >>> 70: -framework SystemConfiguration, \ >>> 71: LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \ >> >> Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms. > > I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113). well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752181579 From alanb at openjdk.org Tue Sep 10 17:40:06 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 10 Sep 2024 17:40:06 GMT Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames [v3] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 21:11:32 GMT, Maurizio Cimadamore wrote: >> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously. >> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context. >> >> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism. >> >> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add copyright Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20914#pullrequestreview-2293235930 From bpb at openjdk.org Tue Sep 10 19:58:48 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Sep 2024 19:58:48 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v6] In-Reply-To: References: Message-ID: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c - Merge - 8337143: Removed dependency of libjava on headers in libnio/ch - 8337143: Move natives to /native/libjava/nio/{ch,fs} as a function of their original location in libnio - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=05 Stats: 1561 lines in 90 files changed: 771 ins; 674 del; 116 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From bpb at openjdk.org Tue Sep 10 20:01:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Sep 2024 20:01:14 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 11:06:28 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c > > src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575: > >> 573: * Used to trigger loading of native libraries >> 574: */ >> 575: public static void load() { } > > do we still need this method? Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752651246 From dholmes at openjdk.org Tue Sep 10 21:34:04 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Sep 2024 21:34:04 GMT Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2] In-Reply-To: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com> References: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com> Message-ID: On Tue, 10 Sep 2024 11:10:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851. >> >> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > update JImageToolTest too Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2293814493 From ihse at openjdk.org Tue Sep 10 21:45:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 10 Sep 2024 21:45:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 15:15:26 GMT, Daniel Jeli?ski wrote: >> I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113). > > well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed. And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752762279 From duke at openjdk.org Tue Sep 10 21:52:16 2024 From: duke at openjdk.org (duke) Date: Tue, 10 Sep 2024 21:52:16 GMT Subject: Withdrawn: 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 pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/16226 From bpb at openjdk.org Tue Sep 10 21:56:11 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Sep 2024 21:56:11 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v5] In-Reply-To: References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> Message-ID: On Fri, 1 Mar 2024 21:48:22 GMT, Brian Burkhalter wrote: >> 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 pull request now contains seven commits: > > - 8315273: Re-remove ToRealPath test > - Merge > - 8315273: Revert ProblemList > - Merge > - Merge > - 8315273: Add bug ID to test > - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) continue; ------------- PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2342073489 From djelinski at openjdk.org Wed Sep 11 06:03:08 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 11 Sep 2024 06:03:08 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 21:42:08 GMT, Magnus Ihse Bursie wrote: >> well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed. > > And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`? Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1753167982 From aivanov at openjdk.org Wed Sep 11 09:10:12 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 11 Sep 2024 09:10:12 GMT Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2] In-Reply-To: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com> References: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com> Message-ID: On Tue, 10 Sep 2024 11:10:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851. >> >> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > update JImageToolTest too Looks good to me. It could be good to remove `@author` tags from all the modified tests. test/jdk/java/beans/Introspector/Test5102804.java line 28: > 26: * @bug 5102804 > 27: * @summary Tests memory leak > 28: * @author Sergey Malenkov Could you also remove the `@author` tag? test/jdk/java/beans/Introspector/Test8027905.java line 30: > 28: * @bug 8027905 > 29: * @summary Tests that GC does not affect a property type > 30: * @author Sergey Malenkov Could you also remove the `@author` tag? ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2296140348 PR Review Comment: https://git.openjdk.org/jdk/pull/20930#discussion_r1753703304 PR Review Comment: https://git.openjdk.org/jdk/pull/20930#discussion_r1753707545 From jpai at openjdk.org Wed Sep 11 09:19:21 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 11 Sep 2024 09:19:21 GMT Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3] In-Reply-To: References: Message-ID: > Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment? > > As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851. > > There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Alexey's suggestion - remove @author tags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20930/files - new: https://git.openjdk.org/jdk/pull/20930/files/8214fdb5..1596c34c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20930&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20930&range=01-02 Stats: 5 lines in 4 files changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20930.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20930/head:pull/20930 PR: https://git.openjdk.org/jdk/pull/20930 From jpai at openjdk.org Wed Sep 11 09:19:21 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 11 Sep 2024 09:19:21 GMT Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2] In-Reply-To: References: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com> Message-ID: <9qOt-WPO0yYRk9G1dd8W2B3i_dIpNdNpoXl7PNb1Jrk=.e1b334d5-3bfa-4549-8dbc-78abf93f17ab@github.com> On Wed, 11 Sep 2024 09:03:58 GMT, Alexey Ivanov wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> update JImageToolTest too > > test/jdk/java/beans/Introspector/Test5102804.java line 28: > >> 26: * @bug 5102804 >> 27: * @summary Tests memory leak >> 28: * @author Sergey Malenkov > > Could you also remove the `@author` tag? Done - I've now updated the PR to remove these author tags. Tests continue to pass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20930#discussion_r1753742813 From aivanov at openjdk.org Wed Sep 11 09:31:07 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 11 Sep 2024 09:31:07 GMT Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai wrote: >> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851. >> >> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alexey's suggestion - remove @author tags Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2296196596 From mcimadamore at openjdk.org Wed Sep 11 11:21:15 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 11 Sep 2024 11:21:15 GMT Subject: Integrated: 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames In-Reply-To: References: Message-ID: <7RjB5Ch6MRlUYvHgnbBM4no5grO25j8oYgpIr3OP4pk=.56d50bdb-3769-4239-ae08-4f45ba35bb66@github.com> On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore wrote: > The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously. > While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context. > > To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism. > > Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context. This pull request has now been integrated. Changeset: 59778885 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk/commit/597788850042e7272a23714c05ba546ee6080856 Stats: 130 lines in 7 files changed: 73 ins; 31 del; 26 mod 8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames 8339780: TestByteBuffer fails on AIX after 8339285 Reviewed-by: alanb, jvernee ------------- PR: https://git.openjdk.org/jdk/pull/20914 From djelinski at openjdk.org Wed Sep 11 11:23:15 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 11 Sep 2024 11:23:15 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v5] In-Reply-To: References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> Message-ID: On Fri, 1 Mar 2024 21:48:22 GMT, Brian Burkhalter wrote: >> 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 pull request now contains seven commits: > > - 8315273: Re-remove ToRealPath test > - Merge > - 8315273: Revert ProblemList > - Merge > - Merge > - 8315273: Add bug ID to test > - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) I don't think we want to do this. On Windows, symbolic links to directories are almost identical to directories: you can have a symbolic link on the path to the working directory, and entering and exiting a symbolic link takes you back to the directory you were originally in. This behavior is observed in many Windows applications. If we change the handling of `..` in paths containing symlinks, Java's interpretation of these paths will be inconsistent with other applications. I think we should relax the ToRealPath test; instead of making assumptions on what toRealPath should return, the test could verify that a file created using a path containing `symlink....\file` can be opened using the path returned by toRealPath. As long as toRealPath points to the same file, the exact path shouldn't matter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2343358526 From ascarpino at openjdk.org Wed Sep 11 16:11:09 2024 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 11 Sep 2024 16:11:09 GMT Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai wrote: >> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851. >> >> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alexey's suggestion - remove @author tags The Cache.java change, and the others, look good to me. ------------- Marked as reviewed by ascarpino (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2297774755 From bpb at openjdk.org Wed Sep 11 16:36:10 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Sep 2024 16:36:10 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Wed, 11 Sep 2024 06:00:23 GMT, Daniel Jeli?ski wrote: >> And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`? > > Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`. >From a clean build in the CI with `mswsock.lib` removed: [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755143206 From prr at openjdk.org Wed Sep 11 16:39:05 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 11 Sep 2024 16:39:05 GMT Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai wrote: >> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851. >> >> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alexey's suggestion - remove @author tags Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2297881944 From djelinski at openjdk.org Wed Sep 11 16:51:08 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 11 Sep 2024 16:51:08 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Wed, 11 Sep 2024 16:33:28 GMT, Brian Burkhalter wrote: >> Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`. > > From a clean build in the CI with `mswsock.lib` removed: > > > [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol > TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0 did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89). There's no FileDispatcherImpl.obj in libnio. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755161852 From djelinski at openjdk.org Wed Sep 11 16:54:07 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 11 Sep 2024 16:54:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com> On Tue, 10 Sep 2024 19:58:45 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575: >> >>> 573: * Used to trigger loading of native libraries >>> 574: */ >>> 575: public static void load() { } >> >> do we still need this method? > > Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions. that's a good point. The comment might need to be updated to reflect that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755166228 From bpb at openjdk.org Wed Sep 11 19:21:07 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Sep 2024 19:21:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com> On Wed, 11 Sep 2024 16:48:24 GMT, Daniel Jeli?ski wrote: >> From a clean build in the CI with `mswsock.lib` removed: >> >> >> [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol >> TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0 > > did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89). > There's no FileDispatcherImpl.obj in libnio. Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755434973 From bpb at openjdk.org Wed Sep 11 19:25:07 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Sep 2024 19:25:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> On Tue, 10 Sep 2024 11:27:05 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c > > src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097: > >> 1095: >> 1096: static { >> 1097: jdk.internal.loader.BootLoader.loadLibrary("net"); > > ...do we still need net here? We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755440401 From ihse at openjdk.org Wed Sep 11 19:34:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 11 Sep 2024 19:34:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com> Message-ID: On Wed, 11 Sep 2024 19:18:18 GMT, Brian Burkhalter wrote: >> did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89). >> There's no FileDispatcherImpl.obj in libnio. > > Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent. Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down. Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755463756 From bpb at openjdk.org Wed Sep 11 19:34:07 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Sep 2024 19:34:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com> Message-ID: <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com> On Wed, 11 Sep 2024 19:28:39 GMT, Magnus Ihse Bursie wrote: >> Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent. > > Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down. > > Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio? I've re-checked it and am running a CI job and will check it again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755467953 From bpb at openjdk.org Wed Sep 11 23:52:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Sep 2024 23:52:14 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v5] In-Reply-To: References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> Message-ID: On Fri, 1 Mar 2024 21:48:22 GMT, Brian Burkhalter wrote: >> 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 pull request now contains seven commits: > > - 8315273: Re-remove ToRealPath test > - Merge > - 8315273: Revert ProblemList > - Merge > - Merge > - 8315273: Add bug ID to test > - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) Consider this case: CWD = C:\Users\bpb\dev\bugs: 1. Create these directories, file, and link in the CWD: file dir\subdir link -> dir\subdir path = link....\file 2. Invoke path.toRealPath: 2.1 mainline results follow links C:\Users\bpb\dev\file no follow links C:\Users\bpb\dev\file 2.2 PR results follow links C:\Users\bpb\dev\bugs\file no follow links C:\Users\bpb\dev\bugs\link....\file The results of the current mainline are incorrect as they locate a non-existent file. The results of the PR version both correctly locate the file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2344985712 From jpai at openjdk.org Thu Sep 12 02:05:09 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 12 Sep 2024 02:05:09 GMT Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai wrote: >> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851. >> >> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alexey's suggestion - remove @author tags Thank you everyone for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20930#issuecomment-2345106667 From jpai at openjdk.org Thu Sep 12 02:05:10 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 12 Sep 2024 02:05:10 GMT Subject: Integrated: 8339834: Replace usages of -mx and -ms in some tests In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 09:46:14 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment? > > As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851. > > There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that. This pull request has now been integrated. Changeset: 1d392492 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/1d392492311daceeae12769cb9494eae63289853 Stats: 22 lines in 9 files changed: 0 ins; 5 del; 17 mod 8339834: Replace usages of -mx and -ms in some tests Reviewed-by: aivanov, ascarpino, prr, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/20930 From bpb at openjdk.org Thu Sep 12 02:10:00 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:00 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: References: Message-ID: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8337143: Clean up to address reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20317/files - new: https://git.openjdk.org/jdk/pull/20317/files/4f47d5a6..853d3491 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=05-06 Stats: 20 lines in 9 files changed: 4 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From bpb at openjdk.org Thu Sep 12 02:10:02 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:02 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 09:54:56 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c > > make/modules/java.base/Lib.gmk line 48: > >> 46: OPTIMIZATION := LOW, \ >> 47: EXTRA_HEADER_DIRS := \ >> 48: libjava/nio/ch, \ > > This appears to be unneeded Agreed. See 853d349. > src/java.base/unix/classes/sun/nio/ch/NativeThread.java line 2: > >> 1: /* >> 2: * Copyright (c) 2002, 2024, Oracle and/or its affiliates. All rights reserved. > > No changes in this file There is one now. 853d349 > src/java.base/unix/native/libnio/ch/NIOUtil.c line 34: > >> 32: #include "jvm.h" >> 33: #include "jlong.h" >> 34: #include "sun_nio_ch_IOUtil.h" > > should this be NIOUtil? Yes. See 853d349. > src/java.base/windows/native/libnio/ch/NIOUtil.c line 41: > >> 39: >> 40: JNIEXPORT jboolean JNICALL >> 41: Java_sun_security_provider_NativeSeedGenerator_nativeGenerateSeed > > unused Removed. 853d349 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983126 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984164 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984274 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755985066 From bpb at openjdk.org Thu Sep 12 02:10:02 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:02 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 13:26:58 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.base/Lib.gmk line 81: >> >>> 79: libjava/nio/ch \ >>> 80: libnio/ch \ >>> 81: libnio/fs \ >> >> libnio/fs is gone on all platforms other than aix; is this still necessary? > > We can't add extra header dirs on a per-platform basis, so if it is needed for AIX it will need to remain here. Otoh, the only "cost" is an additional `-I ` argument to the compiler, so it's not too bad. But if we can remove it, we should, of course. Not changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983319 From bpb at openjdk.org Thu Sep 12 02:10:02 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:02 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com> <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com> Message-ID: <8iOw1S8wQQ6G7-laGTbkZI5rnQjOZrbqv0iZ9BmThTY=.4baaded4-c285-45a2-83c1-d0fd7f3e7ef3@github.com> On Wed, 11 Sep 2024 19:31:02 GMT, Brian Burkhalter wrote: >> Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down. >> >> Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio? > > I've re-checked it and am running a CI job and will check it again. Re-tests passed. See 853d349. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983781 From bpb at openjdk.org Thu Sep 12 02:10:03 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:03 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com> Message-ID: On Wed, 11 Sep 2024 16:51:43 GMT, Daniel Jeli?ski wrote: >> Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions. > > that's a good point. The comment might need to be updated to reflect that. Comments added in 853d349. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983974 From bpb at openjdk.org Thu Sep 12 02:10:03 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:03 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> Message-ID: <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> On Wed, 11 Sep 2024 19:22:00 GMT, Brian Burkhalter wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097: >> >>> 1095: >>> 1096: static { >>> 1097: jdk.internal.loader.BootLoader.loadLibrary("net"); >> >> ...do we still need net here? > > We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit. Moved to `NTLMAuthentication` static initializer. 853d349 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984949 From djelinski at openjdk.org Thu Sep 12 06:27:09 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 12 Sep 2024 06:27:09 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: On Thu, 12 Sep 2024 02:10:00 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Clean up to address reviewer comments Thanks for making the changes. LGTM, assuming that tests still pass. One question in line. src/java.base/unix/native/libjava/nio/fs/UnixNativeDispatcher.c line 221: > 219: static futimesat_func* my_futimesat_func = NULL; > 220: static futimens_func* my_futimens_func = NULL; > 221: #ifndef _ALLBSD_SOURCE This change looks unrelated. Was it intentional? ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2299319884 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1756202839 From djelinski at openjdk.org Thu Sep 12 08:01:13 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 12 Sep 2024 08:01:13 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v5] In-Reply-To: References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> Message-ID: On Fri, 1 Mar 2024 21:48:22 GMT, Brian Burkhalter wrote: >> 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 pull request now contains seven commits: > > - 8315273: Re-remove ToRealPath test > - Merge > - 8315273: Revert ProblemList > - Merge > - Merge > - 8315273: Add bug ID to test > - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) Well let me show you a counterexample: Setup: C:\>mkdir tmp\cwd\dir\subdir C:\>cd tmp\cwd C:\tmp\cwd>mklink /d link dir\subdir symbolic link created for link <<===>> dir\subdir C:\tmp\cwd>jshell.exe Before your changes: jshell> Path.of("link/../../file") $1 ==> link....\file jshell> Files.createFile($1) $2 ==> link....\file jshell> Files.exists($1) $3 ==> true jshell> Files.exists($1.toRealPath()) $4 ==> true After your changes: jshell> Path.of("link/../../file") $1 ==> link....\file jshell> Files.createFile($1) $2 ==> link....\file jshell> Files.exists($1) $3 ==> true jshell> Files.exists($1.toRealPath()) | Exception java.nio.file.NoSuchFileException: C:\tmp\cwd\file | at WindowsException.translateToIOException (WindowsException.java:85) | at WindowsException.rethrowAsIOException (WindowsException.java:103) | at WindowsException.rethrowAsIOException (WindowsException.java:108) | at WindowsLinkSupport.collapseDots (WindowsLinkSupport.java:238) | at WindowsLinkSupport.getRealPath (WindowsLinkSupport.java:285) | at WindowsPath.toRealPath (WindowsPath.java:944) | at WindowsPath.toRealPath (WindowsPath.java:42) | at (#4:1) `path` and `path.toRealPath()` are supposed to point to the same file, but as you can see, this does not happen here. I guess you could adjust all the methods in `Files` class to be consistent with the new `toRealPath` implementation, but this would break consistency with other Windows apps, see for example: C:\tmp\cwd>type file The system cannot find the file specified. C:\tmp\cwd>type link....\file C:\tmp\cwd> Based on the above, I think the current `toRealPath` implementation on Windows is doing just fine, only the `ToRealPath` test needs to be fixed. As far as I could tell, `Path.toRealPath` does not make any promises about what the resulting path should be. The only requirement is that the path should refer to the same file, so the current implementation does not violate the spec. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2345533160 From bpb at openjdk.org Thu Sep 12 15:43:12 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 15:43:12 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: On Thu, 12 Sep 2024 06:24:50 GMT, Daniel Jeli?ski wrote: > Thanks for making the changes. LGTM, assuming that tests still pass. The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating. > src/java.base/unix/native/libjava/nio/fs/UnixNativeDispatcher.c line 221: > >> 219: static futimesat_func* my_futimesat_func = NULL; >> 220: static futimens_func* my_futimens_func = NULL; >> 221: #ifndef _ALLBSD_SOURCE > > This change looks unrelated. Was it intentional? Yes. The variable on the next line `my_lutimes_func` caused an unused variable error in the macOS build. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346633671 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1757123250 From bpb at openjdk.org Thu Sep 12 15:43:13 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 15:43:13 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Thu, 12 Sep 2024 02:05:50 GMT, Brian Burkhalter wrote: >> We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit. > > Moved to `NTLMAuthentication` static initializer. 853d349 @dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1757130549 From alanb at openjdk.org Thu Sep 12 15:46:12 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Sep 2024 15:46:12 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: On Thu, 12 Sep 2024 15:38:18 GMT, Brian Burkhalter wrote: > The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating. Can you hold off integrating, I plan to go over the changes soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346644977 From bpb at openjdk.org Thu Sep 12 15:51:10 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 15:51:10 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: On Thu, 12 Sep 2024 15:43:32 GMT, Alan Bateman wrote: > Can you hold off integrating, I plan to go over the changes soon. I don't plan to integrate until you have reviewed it. I set the minimum reviewer count to 3 to avoid doing so accidentally. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346655197 From pminborg at openjdk.org Thu Sep 12 18:22:42 2024 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 12 Sep 2024 18:22:42 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances Message-ID: This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: | Class File | Base [Bytes] | Patch [Byte] | | --------------------------------| ------------- | ------------ | | FutureTask.class | 10255 | 10154 | | AtomicBoolean.class | 5364 | 5161 | |AtomicMarkableReference.class | 3890 | 3687 | ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) The new `MethodHandlesInternal.class` file is of size 2012 bytes. In total for `java.base` we have: | Build map "jdk" | Size [Bytes] | | ---------------| ------------- | | Base | 5963657 | | Patch | 5962751 | | Delta | 906| For 60 billion instances, this represents 54 TB. ------------- Commit messages: - Fix copyright headers - Introduce MethodHandlesInternal Changes: https://git.openjdk.org/jdk/pull/20972/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325949 Stats: 423 lines in 31 files changed: 109 ins; 202 del; 112 mod Patch: https://git.openjdk.org/jdk/pull/20972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972 PR: https://git.openjdk.org/jdk/pull/20972 From rriggs at openjdk.org Thu Sep 12 19:26:04 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 12 Sep 2024 19:26:04 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 17:38:44 GMT, Per Minborg wrote: > This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. > > While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: > > | Class File | Base [Bytes] | Patch [Byte] | > | --------------------------------| ------------- | ------------ | > | FutureTask.class | 10255 | 10154 | > | AtomicBoolean.class | 5364 | 5161 | > |AtomicMarkableReference.class | 3890 | 3687 | > > ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) > > The new `MethodHandlesInternal.class` file is of size 2012 bytes. > > In total for `java.base` we have: > > | Build map "jdk" | Size [Bytes] | > | ---------------| ------------- | > | Base | 5963657 | > | Patch | 5962751 | > | Delta | 906| > > For 60 billion instances, this represents 54 TB. src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 47: > 45: private MethodHandlesInternal() {} > 46: > 47: public static VarHandle findVarHandleOrThrow(MethodHandles.Lookup lookup, Class recv, String name, Class type) { The method naming might benefit from being clear that failure is fatal; never call it with arguments that might fail. Perhaps even throw java.lang.InternalError. ExceptionInInitializerError might be misconstrued as a some kind of race or being called too early. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1757467476 From liach at openjdk.org Thu Sep 12 19:33:04 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 12 Sep 2024 19:33:04 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 17:38:44 GMT, Per Minborg wrote: > This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. > > While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: > > | Class File | Base [Bytes] | Patch [Byte] | > | --------------------------------| ------------- | ------------ | > | FutureTask.class | 10255 | 10154 | > | AtomicBoolean.class | 5364 | 5161 | > |AtomicMarkableReference.class | 3890 | 3687 | > > ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) > > The new `MethodHandlesInternal.class` file is of size 2012 bytes. > > In total for `java.base` we have: > > | Build map "jdk" | Size [Bytes] | > | ---------------| ------------- | > | Base | 5963657 | > | Patch | 5962751 | > | Delta | 906| > > For 60 billion instances, this represents 54 TB. I think we can elide the `Lookup` argument to perform a always-full-permission lookup operation to simplify call sequence; or, to elide the `recv` receiver argument as it is almost always `lookup.lookupClass()` (except for a few lazy holders) src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 1: > 1: /* I would argue this is closer to invoke than reflect, so can consider moving to `sun.invoke` or even create a new `jdk.internal.invoke` package. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2347081526 PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1757474972 From bpb at openjdk.org Thu Sep 12 20:43:21 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 20:43:21 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v5] In-Reply-To: References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> Message-ID: On Fri, 1 Mar 2024 21:48:22 GMT, Brian Burkhalter wrote: >> 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 pull request now contains seven commits: > > - 8315273: Re-remove ToRealPath test > - Merge > - 8315273: Revert ProblemList > - Merge > - Merge > - 8315273: Add bug ID to test > - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) This does not address your example above with respect to `toRealPath`, but the behavior it shows seems inconsistent. The setup is the same: `/tmp/cwd/dir/subdir` or `C:\tmp\cwd\dir\subdir` where `link` is a symbolic link in `cwd` with the relatve target `dir/subdir`. Then running jshell in `cwd`, the call `Files.createFile(Path.of("link/../../file")` creates `/tmp/cwd/file` on macOS whereas on Windows it creates `C:\tmp\file`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2347200176 From bpb at openjdk.org Thu Sep 12 20:55:11 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 20:55:11 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v17] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:42:23 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. >> >> Test fix only, the change has been verified, risk is low. >> >> Additional test: >> >> - [x] Alinux3 glibc:2.32 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == true >> - [x] CentOS7 docker container glibc:2.17 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == false > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > initail struct stx var to zero For whatever it shows, the test passed on Linux, macOS, and Windows in our CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2347219212 From bpb at openjdk.org Thu Sep 12 21:53:09 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 21:53:09 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v5] In-Reply-To: References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> Message-ID: On Thu, 12 Sep 2024 07:58:21 GMT, Daniel Jeli?ski wrote: > Based on the above, I think the current `toRealPath` implementation on Windows is doing just fine, only the `ToRealPath` test needs to be fixed. Based on these comments in [WindowsPath](https://github.com/openjdk/jdk/blob/81ff91ef27a6a856ae2c453a9a9b8333b91da3ab/src/java.base/windows/classes/sun/nio/fs/WindowsPath.java#L202) // Long paths need to have "." and ".." removed and be prefixed with // "\?". Note that it is okay to remove ".." even when it follows // a link - for example, it is okay for foo/link/../bar to be changed // to foo/bar. The reason is that Win32 APIs to access foo/link/../bar // will access foo/bar anyway (which differs to Unix systems) it seems safe to say that the current `toRealPath()` implementation is, as you say, all right as is. If these comments are correct, then it appears that on Unix the `link` in `foo/link/../bar` would first be resolved and then the `..` would be removed along with the element preceding it, but on Windows, `link` is just treated as a name element without resolution and is summarily removed along with `..`. This is consistent with the `Files.createFile(Path.of("link/../../file"))` example I posted above. > [...] only the `ToRealPath` test needs to be fixed. > > As far as I could tell, `Path.toRealPath` does not make any promises about what the resulting path should be. The only requirement is that the path should refer to the same file, so the current implementation does not violate the spec. At this point, I tend to agree. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2347307267 PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2347308341 From darcy at openjdk.org Fri Sep 13 02:52:37 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 13 Sep 2024 02:52:37 GMT Subject: RFR: 8340082: Use inline return tag in java.base Message-ID: Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug. ------------- Commit messages: - JDK-8340082: Use inline return tag in java.base Changes: https://git.openjdk.org/jdk/pull/20981/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20981&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340082 Stats: 59 lines in 21 files changed: 0 ins; 27 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/20981.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20981/head:pull/20981 PR: https://git.openjdk.org/jdk/pull/20981 From duke at openjdk.org Fri Sep 13 03:15:05 2024 From: duke at openjdk.org (Jason Mehrens) Date: Fri, 13 Sep 2024 03:15:05 GMT Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded, should be mapped to ISO-8859-8 In-Reply-To: References: Message-ID: On Tue, 27 Aug 2024 17:01:19 GMT, Naoto Sato wrote: >> Mapping ISO-8859-8-I charset to ISO-8859-8. >> Below mentioned 2 aliases are added as part of this:- >> **ISO-8859-8-I** >> **ISO8859-8-I** >> >> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686 > > I looked at this issue a bit more. Looking at the IANA Charset registry (https://www.iana.org/assignments/character-sets/character-sets.xhtml) which `Charset` class is based on, `ISO-8859-8-I` is not an alias to `ISO-8859-8`, but it is defined as a distinct `Preferred MIME name`. So I don't think current proposed solution is correct. (It would return ISO-8859-8-I as an alias to ISO-8859-8). Also, looking at the RFC-1556, in which this ISO-8859-8-I encoding is defined, there are other encodings, i.e., ISO-8859-6-I, ISO-8859-6-E, and ISO-8859-8-E. Why are they not relevant, but ISO-8859-8-I is? > Considering these, I am still not sure to introduce these new encodings now, also because there has not been any request from the time Bill Shannon worked (circa 2018), unless Arabic/Hebrew speaking communities jumped in and provide rationale to support them. @naotoj does the mapping need to be removed from: https://github.com/openjdk/jdk/blob/5e5942a282e14846404b68c65d43594d6b9226d9/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java#L770 I ask because JakartaMail /Angus Mail is a similar usecase to this code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2347953621 From iris at openjdk.org Fri Sep 13 03:51:03 2024 From: iris at openjdk.org (Iris Clark) Date: Fri, 13 Sep 2024 03:51:03 GMT Subject: RFR: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy wrote: > Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302073195 From duke at openjdk.org Fri Sep 13 07:05:14 2024 From: duke at openjdk.org (xpbob) Date: Fri, 13 Sep 2024 07:05:14 GMT Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed message for NoSuchFileException Message-ID: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com> (fs) Files.copy include symbolic link detailed message for NoSuchFileException Description Simulation case: touch testfile ln -s testfile testlink mv testfile testfile1 code: public static void main(String[] args) throws IOException { Files.copy(Paths.get("/data/testfiles/testlink"), Paths.get("/data/testfiles/xx")); } Program current information? Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink Devops check file exists with ll After additional information? Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink: due to testfile ------------- Commit messages: - 8340087: (fs) Files.copy include symbolic link detailed message for NoSuchFileException Changes: https://git.openjdk.org/jdk/pull/20984/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20984&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340087 Stats: 25 lines in 1 file changed: 13 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20984.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20984/head:pull/20984 PR: https://git.openjdk.org/jdk/pull/20984 From alanb at openjdk.org Fri Sep 13 07:22:05 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 13 Sep 2024 07:22:05 GMT Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed message for NoSuchFileException In-Reply-To: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com> References: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com> Message-ID: On Fri, 13 Sep 2024 07:00:24 GMT, xpbob wrote: > (fs) Files.copy include symbolic link detailed message for NoSuchFileException > > Description > Simulation case: > > touch testfile > ln -s testfile testlink > mv testfile testfile1 > > > code: > > public static void main(String[] args) throws IOException { > Files.copy(Paths.get("/data/testfiles/testlink"), Paths.get("/data/testfiles/xx")); > } > > > Program current information? > Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink > > > Devops check file exists with ll > > After additional information? > Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink: due to testfile src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1013: > 1011: if (symbolicLink != null) { > 1012: throw new NoSuchFileException(source.toString(), null, "due to " + symbolicLink); > 1013: } The default provider implementation can't use Files.* methods, otherwise you end up with recursive usage. In any case, I think the starting out to decide if anything should change as the existing NoSuchFileException is not wrong. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20984#discussion_r1758314375 From duke at openjdk.org Fri Sep 13 07:32:14 2024 From: duke at openjdk.org (ExE Boss) Date: Fri, 13 Sep 2024 07:32:14 GMT Subject: RFR: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy wrote: > Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug. The?old?version of?the?doc?comments had?a?`.` at?the?end of?the?first?sentence: src/java.base/share/classes/java/io/ObjectInputFilter.java line 1221: > 1219: > 1220: /** > 1221: * {@return the pattern used to create this filter} Suggestion: * {@return the pattern used to create this filter}. src/java.base/share/classes/java/io/ObjectInputStream.java line 3862: > 3860: > 3861: /** > 3862: * {@return the number of bytes read from the input stream} Suggestion: * {@return the number of bytes read from the input stream}. src/java.base/share/classes/java/lang/annotation/Retention.java line 48: > 46: public @interface Retention { > 47: /** > 48: * {@return the retention policy} Suggestion: * {@return the retention policy}. src/java.base/share/classes/java/nio/charset/MalformedInputException.java line 59: > 57: > 58: /** > 59: * {@return the length of the input} Suggestion: * {@return the length of the input}. src/java.base/share/classes/java/nio/charset/MalformedInputException.java line 66: > 64: > 65: /** > 66: * {@return the message} Suggestion: * {@return the message}. src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java line 59: > 57: > 58: /** > 59: * {@return the length of the input} Suggestion: * {@return the length of the input}. src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java line 66: > 64: > 65: /** > 66: * {@return the message} Suggestion: * {@return the message}. src/java.base/share/classes/java/time/format/TextStyle.java line 140: > 138: > 139: /** > 140: * {@return the stand-alone style with the same size} Suggestion: * {@return the stand-alone style with the same size}. src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java line 480: > 478: > 479: /** > 480: * {@return a zero-length array} Suggestion: * {@return a zero-length array}. src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java line 179: > 177: > 178: /** > 179: * {@return the String representation of the current value} Suggestion: * {@return the String representation of the current value}. src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java line 343: > 341: > 342: /** > 343: * {@return the String representation of the current value} Suggestion: * {@return the String representation of the current value}. src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java line 369: > 367: > 368: /** > 369: * {@return the String representation of the current values of array} Suggestion: * {@return the String representation of the current values of array}. src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java line 344: > 342: > 343: /** > 344: * {@return the String representation of the current value} Suggestion: * {@return the String representation of the current value}. src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongArray.java line 369: > 367: > 368: /** > 369: * {@return the String representation of the current values of array} Suggestion: * {@return the String representation of the current values of array}. src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java line 272: > 270: > 271: /** > 272: * {@return the String representation of the current value} Suggestion: * {@return the String representation of the current value}. src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java line 300: > 298: > 299: /** > 300: * {@return the String representation of the current values of array} Suggestion: * {@return the String representation of the current values of array}. src/java.base/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java line 192: > 190: > 191: /** > 192: * {@return the String representation of the current value} Suggestion: * {@return the String representation of the current value}. src/java.base/share/classes/java/util/concurrent/atomic/LongAccumulator.java line 186: > 184: > 185: /** > 186: * {@return the String representation of the current value} Suggestion: * {@return the String representation of the current value}. src/java.base/share/classes/java/util/jar/Manifest.java line 122: > 120: > 121: /** > 122: * {@return the main Attributes for the Manifest} Suggestion: * {@return the main Attributes for the Manifest}. src/java.base/share/classes/java/util/zip/Deflater.java line 785: > 783: > 784: /** > 785: * {@return the ADLER-32 value of the uncompressed data} Suggestion: * {@return the ADLER-32 value of the uncompressed data}. src/java.base/share/classes/java/util/zip/Inflater.java line 285: > 283: > 284: /** > 285: * {@return true if a preset dictionary is needed for decompression} Suggestion: * {@return true if a preset dictionary is needed for decompression}. src/java.base/share/classes/java/util/zip/Inflater.java line 296: > 294: /** > 295: * {@return true if the end of the compressed data stream has been > 296: * reached} Suggestion: * {@return true if the end of the compressed data stream has been * reached}. src/java.base/share/classes/java/util/zip/Inflater.java line 602: > 600: > 601: /** > 602: * {@return the ADLER-32 value of the uncompressed data} Suggestion: * {@return the ADLER-32 value of the uncompressed data}. src/java.base/share/classes/java/util/zip/ZipEntry.java line 141: > 139: > 140: /** > 141: * {@return the name of the entry} Suggestion: * {@return the name of the entry}. src/java.base/share/classes/java/util/zip/ZipFile.java line 501: > 499: > 500: /** > 501: * {@return the path name of the ZIP file} Suggestion: * {@return the path name of the ZIP file}. src/java.base/share/classes/java/util/zip/ZipFile.java line 562: > 560: > 561: /** > 562: * {@return an enumeration of the ZIP file entries} Suggestion: * {@return an enumeration of the ZIP file entries}. ------------- PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302321414 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758326174 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758326396 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758326761 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327147 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327483 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327766 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327939 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328188 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328373 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328561 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328660 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328760 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328833 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328935 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329031 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329171 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329268 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329376 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329468 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329520 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329601 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329771 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329873 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758330051 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758330157 PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758330290 From pminborg at openjdk.org Fri Sep 13 07:42:05 2024 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 13 Sep 2024 07:42:05 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 19:29:47 GMT, Chen Liang wrote: > I think we can elide the `Lookup` argument to perform a always-full-permission lookup operation to simplify call sequence; or, to elide the `recv` receiver argument as it is almost always `lookup.lookupClass()` (except for a few lazy holders) If we could access `MethodHandles.Lookup.IMPL_LOOKUP `, we could use this as a lookup and elide the lookup arg. Any ideas to do this in a "polite" way? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2348250197 From pminborg at openjdk.org Fri Sep 13 07:50:49 2024 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 13 Sep 2024 07:50:49 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v2] In-Reply-To: References: Message-ID: > This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. > > While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: > > | Class File | Base [Bytes] | Patch [Byte] | > | --------------------------------| ------------- | ------------ | > | FutureTask.class | 10255 | 10154 | > | AtomicBoolean.class | 5364 | 5161 | > |AtomicMarkableReference.class | 3890 | 3687 | > > ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) > > The new `MethodHandlesInternal.class` file is of size 2012 bytes. > > In total for `java.base` we have: > > | Build map "jdk" | Size [Bytes] | > | ---------------| ------------- | > | Base | 5963657 | > | Patch | 5962751 | > | Delta | 906| > > For 60 billion instances, this represents 54 TB. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Rename and reformat ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20972/files - new: https://git.openjdk.org/jdk/pull/20972/files/87d7a477..1dee24ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=00-01 Stats: 98 lines in 31 files changed: 32 ins; 3 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/20972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972 PR: https://git.openjdk.org/jdk/pull/20972 From alanb at openjdk.org Fri Sep 13 07:50:49 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 13 Sep 2024 07:50:49 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 07:39:40 GMT, Per Minborg wrote: > If we could access `MethodHandles.Lookup.IMPL_LOOKUP `, we could use this as a lookup and elide the lookup arg. Any ideas to do this in a "polite" way? Lookup.IMPL_LOOKUP should be guarded closely, I don't think we should remove the need to provide a Lookup with the appropriate access. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2348266276 From duke at openjdk.org Fri Sep 13 08:54:19 2024 From: duke at openjdk.org (xpbob) Date: Fri, 13 Sep 2024 08:54:19 GMT Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed message for NoSuchFileException [v2] In-Reply-To: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com> References: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com> Message-ID: <1HCAbXIVJfinjn69DXgqFLCou6dZypPfJ95W2kOT1Ng=.341c8626-709b-4ee8-b8c3-527f9d390c89@github.com> > (fs) Files.copy include symbolic link detailed message for NoSuchFileException > > Description > Simulation case: > > touch testfile > ln -s testfile testlink > mv testfile testfile1 > > > code: > > public static void main(String[] args) throws IOException { > Files.copy(Paths.get("/data/testfiles/testlink"), Paths.get("/data/testfiles/xx")); > } > > > Program current information? > Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink > > > Devops check file exists with ll > > After additional information? > Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink: due to testfile xpbob has updated the pull request incrementally with one additional commit since the last revision: Reimport package ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20984/files - new: https://git.openjdk.org/jdk/pull/20984/files/0a205908..c19142e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20984&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20984&range=00-01 Stats: 14 lines in 1 file changed: 13 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20984.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20984/head:pull/20984 PR: https://git.openjdk.org/jdk/pull/20984 From duke at openjdk.org Fri Sep 13 08:54:20 2024 From: duke at openjdk.org (xpbob) Date: Fri, 13 Sep 2024 08:54:20 GMT Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed message for NoSuchFileException [v2] In-Reply-To: References: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com> Message-ID: <3hQD-SREYfMb0rBGLvRd-wlNp9iUibrRhiUIFLHqS4c=.947022c4-56dd-4ff0-8473-fa2700f1597d@github.com> On Fri, 13 Sep 2024 07:19:11 GMT, Alan Bateman wrote: >> xpbob has updated the pull request incrementally with one additional commit since the last revision: >> >> Reimport package > > src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1013: > >> 1011: if (symbolicLink != null) { >> 1012: throw new NoSuchFileException(source.toString(), null, "due to " + symbolicLink); >> 1013: } > > The default provider implementation can't use Files.* methods, otherwise you end up with recursive usage. > > In any case, I think the starting out to decide if anything should change as the existing NoSuchFileException is not wrong. Thanks for review @AlanBateman The NoSuchFileException in this case is correct,The code is to add contextual information for NoSuchFileException. In this case, the symlinked file does not exist, the symlink exist. NoSuchFileException info is symlink. `ls path to symlink` The detection file exists.This is supposed to detect the symlinked file.Expect to add symbolic link information in the NoSuchFileException before Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink after Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink: due to testfile The condition for throwing a NoSuchFileException has not changed private IOException translateToIOException(String file, String other) { ?? if (errno() == UnixConstants.ENOENT) return new NoSuchFileException(file, other, null); ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20984#discussion_r1758459486 From prappo at openjdk.org Fri Sep 13 09:16:05 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 13 Sep 2024 09:16:05 GMT Subject: RFR: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 07:29:00 GMT, ExE Boss wrote: > The?old?version of?the?doc?comments had?a?`.` at?the?end of?the?first?sentence: The new version has it too, but in the final, generated form: https://docs.oracle.com/en/java/javase/22/docs/specs/javadoc/doc-comment-spec.html#return `{@return blah}` expands to `Returns blah.` ------------- PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2348446043 From sgehwolf at openjdk.org Fri Sep 13 09:32:12 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 13 Sep 2024 09:32:12 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v17] In-Reply-To: References: Message-ID: <_9KiXoXklJePuiscdaV9D9RiM_dvq4oPtmGqgBQ0TW0=.a41f4787-ed84-4a5a-81fb-3438c0dd9db5@github.com> On Thu, 12 Sep 2024 20:52:13 GMT, Brian Burkhalter wrote: > For whatever it shows, the test passed on Linux, macOS, and Windows in our CI. @bplb Do you mean the updated one in this PR or the old one without this patch? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2348481147 From duke at openjdk.org Fri Sep 13 09:48:05 2024 From: duke at openjdk.org (ExE Boss) Date: Fri, 13 Sep 2024 09:48:05 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v2] In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 19:30:45 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename and reformat > > src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 1: > >> 1: /* > > I would argue this is closer to invoke than reflect, so can consider moving to `sun.invoke` or even create a new `jdk.internal.invoke` package. I?m?in?favour of?introducing `jdk.internal.invoke`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1758550297 From prappo at openjdk.org Fri Sep 13 10:24:04 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 13 Sep 2024 10:24:04 GMT Subject: RFR: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: <63jr3o7GvnCQc-Fftek57SoIO58BsAblgKia69hF5fo=.733822a2-8ba0-42fd-a6bb-eb7bcb641bbc@github.com> On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy wrote: > Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug. Thanks, Joe. This looks good, especially considering that the change was produced with the help of a quick-and-dirty, regex-based script. This change is certainly enough to spread awareness of this relatively new javadoc feature. I remember I had a more involved script that used `javax.lang.model` and string similarity metrics. That script captured a lot more candidates for `{@return}`. But on the other hand, once you start considering non-exact matches, it requires human judgement and increases review effort. --- Separately, this PR has helped me put a finger on what I __don't__ like about `{@return}`. What I don't like is the generated HTML. `{@return}` saves mental effort when reading raw javadoc in source, but it provides no similar service to the reader of the final, HTML form. Maybe it's just me, but it looks needlessly bloated and silly: browser screenshot of javax.lang.model.element.AnnotationValue#getValue Maybe if a method's main description consisted only of `{@return}`, we could skip the first sentence in the "Method Details" section and just output `Returns:`? Any further discussion should happen on the javadoc-dev mailing list. ------------- Marked as reviewed by prappo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302744094 From lancea at openjdk.org Fri Sep 13 12:18:04 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 13 Sep 2024 12:18:04 GMT Subject: RFR: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy wrote: > Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug. I went through the changes and they look fine. ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302964654 From liach at openjdk.org Fri Sep 13 12:43:05 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 13 Sep 2024 12:43:05 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v2] In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 07:50:49 GMT, Per Minborg wrote: >> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. >> >> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: >> >> | Class File | Base [Bytes] | Patch [Byte] | >> | --------------------------------| ------------- | ------------ | >> | FutureTask.class | 10255 | 10154 | >> | AtomicBoolean.class | 5364 | 5161 | >> |AtomicMarkableReference.class | 3890 | 3687 | >> >> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) >> >> The new `MethodHandlesInternal.class` file is of size 2012 bytes. >> >> In total for `java.base` we have: >> >> | Build map "jdk" | Size [Bytes] | >> | ---------------| ------------- | >> | Base | 5963657 | >> | Patch | 5962751 | >> | Delta | 906| >> >> For 60 billion instances, this represents 54 TB. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Rename and reformat src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 50: > 48: private MethodHandlesInternal() {} > 49: > 50: public static VarHandle findVarHandle(MethodHandles.Lookup lookup, Do you think we should create a 3-arg overload like `Lookup lookup, String name, Class type` that calls `findVarHandle(lookup, lookup.lookupClass(), name, type);` for ease of use at many call sites? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1758795681 From liach at openjdk.org Fri Sep 13 13:10:06 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 13 Sep 2024 13:10:06 GMT Subject: RFR: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy wrote: > Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug. This patch only captures one-line returns without extra sentences. Is it possible for us to handle slightly more complex documentations like `ParameterizedType::getActualTypeArguments`? https://github.com/openjdk/jdk/blob/f7cb6e23194c8e08a699eca84ae9b424c0283588/src/java.base/share/classes/java/lang/reflect/ParameterizedType.java#L50-L58 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2348921651 From prappo at openjdk.org Fri Sep 13 13:17:03 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 13 Sep 2024 13:17:03 GMT Subject: RFR: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 13:07:03 GMT, Chen Liang wrote: > This patch only captures one-line returns without extra sentences. Is it possible for us to handle slightly more complex documentations like `ParameterizedType::getActualTypeArguments`? Sure, it is possible. However, there's a tradeoff between comprehensiveness and the effort required. Joe's script provides a lot for a little. If there's interest in it, we could file follow-up bugs to fix more cases with more powerful tools. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2348937038 From djelinski at openjdk.org Fri Sep 13 13:26:05 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 13 Sep 2024 13:26:05 GMT Subject: RFR: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy wrote: > Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2303131739 From pminborg at openjdk.org Fri Sep 13 14:46:09 2024 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 13 Sep 2024 14:46:09 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v2] In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 12:40:33 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename and reformat > > src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 50: > >> 48: private MethodHandlesInternal() {} >> 49: >> 50: public static VarHandle findVarHandle(MethodHandles.Lookup lookup, > > Do you think we should create a 3-arg overload like `Lookup lookup, String name, Class type` that calls `findVarHandle(lookup, lookup.lookupClass(), name, type);` for ease of use at many call sites? The pro: Simpler code at the call site. The con: it is a bit magic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1758999490 From bpb at openjdk.org Fri Sep 13 15:45:10 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 15:45:10 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v17] In-Reply-To: <_9KiXoXklJePuiscdaV9D9RiM_dvq4oPtmGqgBQ0TW0=.a41f4787-ed84-4a5a-81fb-3438c0dd9db5@github.com> References: <_9KiXoXklJePuiscdaV9D9RiM_dvq4oPtmGqgBQ0TW0=.a41f4787-ed84-4a5a-81fb-3438c0dd9db5@github.com> Message-ID: On Fri, 13 Sep 2024 09:29:05 GMT, Severin Gehwolf wrote: > > For whatever it shows, the test passed on Linux, macOS, and Windows in our CI. > > @bplb Do you mean the updated one in this PR or the old one without this patch? @jerboaa The latest version in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2349252518 From dfuchs at openjdk.org Fri Sep 13 16:11:15 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 13 Sep 2024 16:11:15 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Thu, 12 Sep 2024 15:40:27 GMT, Brian Burkhalter wrote: >> Moved to `NTLMAuthentication` static initializer. 853d349 > > @dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load? hmm... I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759124071 From sgehwolf at openjdk.org Fri Sep 13 16:11:14 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 13 Sep 2024 16:11:14 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v17] In-Reply-To: References: <_9KiXoXklJePuiscdaV9D9RiM_dvq4oPtmGqgBQ0TW0=.a41f4787-ed84-4a5a-81fb-3438c0dd9db5@github.com> Message-ID: <8N4EQ5QRKomSaNrHYN1Vo-K_S35rRw042SNe8Oom5us=.6a4bac69-eea5-4c96-b858-36bbe7bd4458@github.com> On Fri, 13 Sep 2024 15:42:43 GMT, Brian Burkhalter wrote: > > > For whatever it shows, the test passed on Linux, macOS, and Windows in our CI. > > > > > > @bplb Do you mean the updated one in this PR or the old one without this patch? > > @jerboaa The latest version in this PR. OK, thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2349301991 From dfuchs at openjdk.org Fri Sep 13 16:11:15 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 13 Sep 2024 16:11:15 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Fri, 13 Sep 2024 16:05:37 GMT, Daniel Fuchs wrote: >> @dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load? > > hmm... I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication. I wonder - do you see any failure if you don't load libnet from there? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759125047 From bpb at openjdk.org Fri Sep 13 16:11:15 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 16:11:15 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Fri, 13 Sep 2024 16:06:26 GMT, Daniel Fuchs wrote: >> hmm... I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication. > > I wonder - do you see any failure if you don't load libnet from there? Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759128167 From bpb at openjdk.org Fri Sep 13 16:15:16 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 16:15:16 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Fri, 13 Sep 2024 16:08:50 GMT, Brian Burkhalter wrote: >> I wonder - do you see any failure if you don't load libnet from there? > > Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`. > [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication. In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759132986 From bpb at openjdk.org Fri Sep 13 16:19:06 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 16:19:06 GMT Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed message for NoSuchFileException [v2] In-Reply-To: <3hQD-SREYfMb0rBGLvRd-wlNp9iUibrRhiUIFLHqS4c=.947022c4-56dd-4ff0-8473-fa2700f1597d@github.com> References: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com> <3hQD-SREYfMb0rBGLvRd-wlNp9iUibrRhiUIFLHqS4c=.947022c4-56dd-4ff0-8473-fa2700f1597d@github.com> Message-ID: <_MswEWenPCynJ2_FdOi7wq00ICbn_Fc2RHVcbHURQfw=.02fb4365-1959-4f4c-a5be-bbbf3cd95c23@github.com> On Fri, 13 Sep 2024 08:49:22 GMT, xpbob wrote: >> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1013: >> >>> 1011: if (symbolicLink != null) { >>> 1012: throw new NoSuchFileException(source.toString(), null, "due to " + symbolicLink); >>> 1013: } >> >> The default provider implementation can't use Files.* methods, otherwise you end up with recursive usage. >> >> In any case, I think the starting out to decide if anything should change as the existing NoSuchFileException is not wrong. > > Thanks for review > @AlanBateman > The NoSuchFileException in this case is correct,The code is to add contextual information for NoSuchFileException. > > > In this case, the symlinked file does not exist, the symlink exist. > > NoSuchFileException info is symlink. > > `ls path to symlink` The detection file exists.This is supposed to detect the symlinked file.Expect to add symbolic link information in the NoSuchFileException > > before > > Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink > > after > > Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink: due to testfile > > > > > > The condition for throwing a NoSuchFileException has not changed > > > private IOException translateToIOException(String file, String other) { > ?? > if (errno() == UnixConstants.ENOENT) > return new NoSuchFileException(file, other, null); > ?? > The default provider implementation can't use Files.* methods, otherwise you end up with recursive usage. `UnixFileSystemProvider` is what I think ought to be used instead. > In any case, I think the starting out to decide if anything should change as the existing NoSuchFileException is not wrong. Please see [2. Socialize your change](https://openjdk.org/guide/#socialize-your-change). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20984#discussion_r1759138049 From dfuchs at openjdk.org Fri Sep 13 16:34:08 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 13 Sep 2024 16:34:08 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Fri, 13 Sep 2024 16:12:28 GMT, Brian Burkhalter wrote: >> Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`. > >> [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication. > > In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`. Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759158214 From naoto at openjdk.org Fri Sep 13 16:34:09 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 13 Sep 2024 16:34:09 GMT Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded, should be mapped to ISO-8859-8 In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 03:12:39 GMT, Jason Mehrens wrote: >> I looked at this issue a bit more. Looking at the IANA Charset registry (https://www.iana.org/assignments/character-sets/character-sets.xhtml) which `Charset` class is based on, `ISO-8859-8-I` is not an alias to `ISO-8859-8`, but it is defined as a distinct `Preferred MIME name`. So I don't think current proposed solution is correct. (It would return ISO-8859-8-I as an alias to ISO-8859-8). Also, looking at the RFC-1556, in which this ISO-8859-8-I encoding is defined, there are other encodings, i.e., ISO-8859-6-I, ISO-8859-6-E, and ISO-8859-8-E. Why are they not relevant, but ISO-8859-8-I is? >> Considering these, I am still not sure to introduce these new encodings now, also because there has not been any request from the time Bill Shannon worked (circa 2018), unless Arabic/Hebrew speaking communities jumped in and provide rationale to support them. > > @naotoj does the mapping need to be removed from: > > https://github.com/openjdk/jdk/blob/5e5942a282e14846404b68c65d43594d6b9226d9/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java#L770 > > I ask because JakartaMail /Angus Mail is a similar usecase to this code. @jmehrens I would like to, but I don't know the possible issues that would be caused by the removal. So my take is no. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2349349814 From bpb at openjdk.org Fri Sep 13 16:38:09 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 16:38:09 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Fri, 13 Sep 2024 16:31:36 GMT, Daniel Fuchs wrote: >>> [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication. >> >> In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`. > > Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM. I would have to check. The failure I observed occurred in both of these tests test/jdk/sun/net/www/protocol/http/NoNTLM.java test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java and nowhere else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759166801 From darcy at openjdk.org Fri Sep 13 16:38:10 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 13 Sep 2024 16:38:10 GMT Subject: RFR: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 13:13:58 GMT, Pavel Rappo wrote: > > This patch only captures one-line returns without extra sentences. Is it possible for us to handle slightly more complex documentations like `ParameterizedType::getActualTypeArguments`? > > Sure, it is possible. However, there's a tradeoff between comprehensiveness and the effort required. Joe's script provides a lot for a little. > > If there's interest in it, we could file follow-up bugs to fix more cases with more powerful tools. Yes, the quick and dirty program is only a "minimum viable product" level of functionality. It is not complete and doesn't catch all cases. Future improvements welcome! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2349358796 From naoto at openjdk.org Fri Sep 13 16:38:09 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 13 Sep 2024 16:38:09 GMT Subject: RFR: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: <0fjq3uhnar6RlEAQ2heD004puGip3pLT9_0_t2Pb2hY=.c53994c7-c392-432b-8352-b9c808622d13@github.com> On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy wrote: > Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug. `java.nio.charset` and `java.time.format` changes look good ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2303567979 From dfuchs at openjdk.org Fri Sep 13 16:48:12 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 13 Sep 2024 16:48:12 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com> On Fri, 13 Sep 2024 16:35:04 GMT, Brian Burkhalter wrote: >> Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM. > > I would have to check. The failure I observed occurred in both of these tests > > test/jdk/sun/net/www/protocol/http/NoNTLM.java > test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java > > and nowhere else. I see. The test does: Class ntlmProxyClass = Class.forName("sun.net.www.protocol.http.NTLMAuthenticationProxy", true, NoNTLM.class.getClassLoader()); so that explains it. In this case I believe it's fair enough to have NTLMAuthentication trigger the loading of libnet if not loaded already -since we need that library to perform the class initialization properly. What you have is good to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759183851 From liach at openjdk.org Fri Sep 13 16:52:08 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 13 Sep 2024 16:52:08 GMT Subject: RFR: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: <3pXE4pv6hyvGSEe1JBp2R6CchhZvSKzjKol3UVdPkRI=.983e0a29-3ac0-4682-a4a5-e5fb17a0ed85@github.com> On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy wrote: > Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug. Looks good. It might be feasible to run a more complex tool that analyzes the tokenized javadoc AST from javac as later work. Annotation changes look good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2303605703 From darcy at openjdk.org Fri Sep 13 16:52:09 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 13 Sep 2024 16:52:09 GMT Subject: Integrated: 8340082: Use inline return tag in java.base In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy wrote: > Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug. This pull request has now been integrated. Changeset: 89c172ac Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/89c172ac47a9cc238739338417015bf912ad5424 Stats: 59 lines in 21 files changed: 0 ins; 27 del; 32 mod 8340082: Use inline return tag in java.base Reviewed-by: iris, prappo, lancea, djelinski, naoto, liach ------------- PR: https://git.openjdk.org/jdk/pull/20981 From bpb at openjdk.org Fri Sep 13 17:06:08 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 17:06:08 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com> Message-ID: <0IMOcZubegYzX-gY4eVUoKl6dSj4FUUkLVO6zYwhTxU=.e0d23617-85fb-4075-be9a-b245205497df@github.com> On Fri, 13 Sep 2024 16:45:22 GMT, Daniel Fuchs wrote: >> I would have to check. The failure I observed occurred in both of these tests >> >> test/jdk/sun/net/www/protocol/http/NoNTLM.java >> test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java >> >> and nowhere else. > > I see. The test does: > > Class ntlmProxyClass = Class.forName("sun.net.www.protocol.http.NTLMAuthenticationProxy", true, NoNTLM.class.getClassLoader()); > > so that explains it. > > In this case I believe it's fair enough to have NTLMAuthentication trigger the loading of libnet if not loaded already -since we need that library to perform the class initialization properly. > > What you have is good to me. Good! Thanks for the assistance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759204325 From ihse at openjdk.org Fri Sep 13 19:33:18 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 13 Sep 2024 19:33:18 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com> On Thu, 12 Sep 2024 02:10:00 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Clean up to address reviewer comments make/modules/java.base/lib/CoreLibraries.gmk line 68: > 66: JDK_LIBS := libjvm, \ > 67: LIBS_linux := $(LIBDL) -lpthread, \ > 68: LIBS_aix := $(LIBDL) $(LIBM),\ Suggestion: LIBS_aix := $(LIBDL) $(LIBM), \ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759390367 From bpb at openjdk.org Fri Sep 13 19:42:27 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 19:42:27 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v6] 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: > 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 pull request now contains nine commits: - 8315273: Revert source changes; update test to match reality; correct a small type in Files - Merge - 8315273: Re-remove ToRealPath test - Merge - 8315273: Revert ProblemList - Merge - Merge - 8315273: Add bug ID to test - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) ------------- Changes: https://git.openjdk.org/jdk/pull/15525/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15525&range=05 Stats: 26 lines in 3 files changed: 20 ins; 2 del; 4 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 bpb at openjdk.org Fri Sep 13 20:41:27 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 20:41:27 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v8] In-Reply-To: References: Message-ID: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com> > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8337143: Minor makefile tweak ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20317/files - new: https://git.openjdk.org/jdk/pull/20317/files/853d3491..b54b1683 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From bpb at openjdk.org Fri Sep 13 20:41:28 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 20:41:28 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com> References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com> Message-ID: <8y7e4b_Phw8ehQRM0kbQom0w3WD91u7B5ujYIiGl6P4=.eab2e1ad-3a81-4c7e-8e14-cc6b51a377d0@github.com> On Fri, 13 Sep 2024 19:30:42 GMT, Magnus Ihse Bursie wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8337143: Clean up to address reviewer comments > > make/modules/java.base/lib/CoreLibraries.gmk line 68: > >> 66: JDK_LIBS := libjvm, \ >> 67: LIBS_linux := $(LIBDL) -lpthread, \ >> 68: LIBS_aix := $(LIBDL) $(LIBM),\ > > Suggestion: > > LIBS_aix := $(LIBDL) $(LIBM), \ So changed in b54b168. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759474420 From duke at openjdk.org Fri Sep 13 23:55:08 2024 From: duke at openjdk.org (Jason Mehrens) Date: Fri, 13 Sep 2024 23:55:08 GMT Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded, should be mapped to ISO-8859-8 In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 16:31:21 GMT, Naoto Sato wrote: >> @naotoj does the mapping need to be removed from: >> >> https://github.com/openjdk/jdk/blob/5e5942a282e14846404b68c65d43594d6b9226d9/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java#L770 >> >> I ask because JakartaMail /Angus Mail is a similar usecase to this code. > > @jmehrens I would like to, but I don't know the possible issues that would be caused by the removal. So my take is no. @naotoj Makes sense. I did find a few links: https://blog.netbsd.org/tnf/entry/handling_non_utf_8_hebrew https://support.oracle.com/knowledge/Oracle%20Cloud/2991085_1.html Any advice on adding the alias to JakartaMail? I see web search results of libraries using what is done in xerces so I'm trying to balance your advice with that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2350716557 From syan at openjdk.org Sat Sep 14 01:47:10 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 14 Sep 2024 01:47:10 GMT Subject: RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v17] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:42:23 GMT, SendaoYan wrote: >> Hi all, >> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time). >> >> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time. >> >> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not. >> >> Test fix only, the change has been verified, risk is low. >> >> Additional test: >> >> - [x] Alinux3 glibc:2.32 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == true >> - [x] CentOS7 docker container glibc:2.17 >> 1. /tmp/file supportsCreationTimeRead == false >> 2. ./file supportsCreationTimeRead == false > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > initail struct stx var to zero > > > For whatever it shows, the test passed on Linux, macOS, and Windows in our CI. > @jerboaa The latest version in this PR. Thanks for the test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2350773023 From djelinski at openjdk.org Mon Sep 16 09:48:10 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 16 Sep 2024 09:48:10 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v6] In-Reply-To: References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> Message-ID: On Fri, 13 Sep 2024 19:42:27 GMT, Brian Burkhalter wrote: >> 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 pull request now contains nine commits: > > - 8315273: Revert source changes; update test to match reality; correct a small type in Files > - Merge > - 8315273: Re-remove ToRealPath test > - Merge > - 8315273: Revert ProblemList > - Merge > - Merge > - 8315273: Add bug ID to test > - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15525#pullrequestreview-2306177970 From duke at openjdk.org Mon Sep 16 10:22:05 2024 From: duke at openjdk.org (Kasper Nielsen) Date: Mon, 16 Sep 2024 10:22:05 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v2] In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 07:50:49 GMT, Per Minborg wrote: >> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. >> >> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: >> >> | Class File | Base [Bytes] | Patch [Byte] | >> | --------------------------------| ------------- | ------------ | >> | FutureTask.class | 10255 | 10154 | >> | AtomicBoolean.class | 5364 | 5161 | >> |AtomicMarkableReference.class | 3890 | 3687 | >> >> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) >> >> The new `MethodHandlesInternal.class` file is of size 2012 bytes. >> >> In total for `java.base` we have: >> >> | Build map "jdk" | Size [Bytes] | >> | ---------------| ------------- | >> | Base | 5963657 | >> | Patch | 5962751 | >> | Delta | 906| >> >> For 60 billion instances, this represents 54 TB. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Rename and reformat This would actually be super useful in a public API. I use the same "trick" in some of my projects. Not because I care too much about the classfile size. But it is just a lot easier on the eye. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2352521927 From ihse at openjdk.org Mon Sep 16 10:22:11 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 16 Sep 2024 10:22:11 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v8] In-Reply-To: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com> References: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com> Message-ID: On Fri, 13 Sep 2024 20:41:27 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Minor makefile tweak Make changes look fine now. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2306245227 From pminborg at openjdk.org Mon Sep 16 12:01:26 2024 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 16 Sep 2024 12:01:26 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v3] In-Reply-To: References: Message-ID: > This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. > > While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: > > | Class File | Base [Bytes] | Patch [Byte] | > | --------------------------------| ------------- | ------------ | > | FutureTask.class | 10,255 | 10,123 | > | AtomicBoolean.class | 5,364 | 5,134 | > |AtomicMarkableReference.class | 3,890 | 3,660 | > > ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) > > The new `MethodHandlesInternal.class` file is of size 1,952 bytes. > > In total for `java.base` we have: > > | Build map "jdk" | Size [Bytes] | > | ---------------| ------------- | > | Base | 5,906,457 | > | Patch | 5,905,487 | > | Delta | 940| > > For 60 billion instances, this represents > 50 TB. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Move to new package and add overload - Merge branch 'master' into internal-mh-util - Rename and reformat - Fix copyright headers - Introduce MethodHandlesInternal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20972/files - new: https://git.openjdk.org/jdk/pull/20972/files/1dee24ab..e2e935b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=01-02 Stats: 9768 lines in 215 files changed: 6742 ins; 1600 del; 1426 mod Patch: https://git.openjdk.org/jdk/pull/20972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972 PR: https://git.openjdk.org/jdk/pull/20972 From naoto at openjdk.org Mon Sep 16 17:43:08 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 16 Sep 2024 17:43:08 GMT Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded, should be mapped to ISO-8859-8 In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant wrote: > Mapping ISO-8859-8-I charset to ISO-8859-8. > Below mentioned 2 aliases are added as part of this:- > **ISO-8859-8-I** > **ISO8859-8-I** > > The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686 Sorry, but I cannot speak for Jakarta Mail. If they see ISO-8859-8-I encoding important, they may introduce it as a new charset (again it is not an alias to ISO-8859-8) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2353528689 From duke at openjdk.org Mon Sep 16 22:03:09 2024 From: duke at openjdk.org (duke) Date: Mon, 16 Sep 2024 22:03:09 GMT Subject: Withdrawn: 8316882: Do not close ZipFileSystem on interrupt In-Reply-To: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com> References: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com> Message-ID: On Sun, 21 Jul 2024 13:29:36 GMT, Technici4n wrote: > Hi, > > Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882, following the `FileChannelImpl#setUninterruptible` pattern used in `Files.readAllBytes` for example. > > There has been some discussion on nio-dev about more broadly rethinking the interrupt handling for `FileChannels`, for example by adding a new open option. This PR is just meant to fix the ZipFS issue in the meanwhile. (Maybe I will tackle the more general issue?). [1] [2] > > [1]: https://mail.openjdk.org/pipermail/nio-dev/2018-February/004756.html > [2]: https://mail.openjdk.org/pipermail/nio-dev/2024-April/016147.html This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20274 From bpb at openjdk.org Mon Sep 16 23:52:13 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 16 Sep 2024 23:52:13 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v6] In-Reply-To: References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> Message-ID: On Fri, 13 Sep 2024 19:42:27 GMT, Brian Burkhalter wrote: >> 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 pull request now contains nine commits: > > - 8315273: Revert source changes; update test to match reality; correct a small type in Files > - Merge > - 8315273: Re-remove ToRealPath test > - Merge > - 8315273: Revert ProblemList > - Merge > - Merge > - 8315273: Add bug ID to test > - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) In `C:\Users\bpb\dev\bugs`, create `dir`, `dir\subdir`, and `link -> dir\subdir`. Then running a simple native test using `CreateFileW` to create a new file `C:\Users\bpb\dev\bugs\link..\file.txt` actually creates `C:\Users\bpb\dev\bugs\file.txt`, which corroborates the conclusion of this PR. The initial version of this PR incorrectly expected that `file.txt` would be `C:\Users\bpb\dev\bugs\dir\file.txt`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2354225541 From duke at openjdk.org Tue Sep 17 03:04:11 2024 From: duke at openjdk.org (Jason Mehrens) Date: Tue, 17 Sep 2024 03:04:11 GMT Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded, should be mapped to ISO-8859-8 In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 17:40:38 GMT, Naoto Sato wrote: >> Mapping ISO-8859-8-I charset to ISO-8859-8. >> Below mentioned 2 aliases are added as part of this:- >> **ISO-8859-8-I** >> **ISO8859-8-I** >> >> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686 > > Sorry, but I cannot speak for Jakarta Mail. If they see ISO-8859-8-I encoding important, they may introduce it as a new charset (again it is not an alias to ISO-8859-8) @naotoj >Sorry, but I cannot speak for Jakarta Mail. If they see ISO-8859-8-I encoding important, they may introduce it as a new charset (again it is not an alias to ISO-8859-8) Understood. I'll close out those tickets then with alternatives. >...Considering these, I am still not sure to introduce these new encodings now, also because there has not been any request from the time Bill Shannon worked (circa 2018) Well that is not exactly true. The following are all the same ticket from 2018 as a request from JavaMail/JakartaMail: - https://bugs.openjdk.org/browse/JDK-8195686 (Ticket created by JavaMail user against OpenJDK by @jmiserez) - https://github.com/jakartaee/mail-api/issues/302 (migrated ticket from JavaMail to JakartaMail) - https://github.com/javaee/javamail/issues/302 (referenced in JDK-8195686 by @jmiserez) The OpenJDK ticket JDK-8195686 has not had a proper evaluation since 2018. However, looks like this PR has that covered and I'm grateful for that. Then in May of 2024 the following was created: https://github.com/eclipse-ee4j/angus-mail/issues/147 by @davecrighton on the Angus Mail project. Then in June @psawant19 commented on that ticket and later created this PR in OpenJDK. So 3 unique users and all related to JavaMail/JakartaMail/Angus Mail on this very topic. It seems pretty clear that we would have to contribute the new Charset implementation to move this forward. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2354412752 From duke at openjdk.org Tue Sep 17 05:34:05 2024 From: duke at openjdk.org (Jeremie Miserez) Date: Tue, 17 Sep 2024 05:34:05 GMT Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded, should be mapped to ISO-8859-8 In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant wrote: > Mapping ISO-8859-8-I charset to ISO-8859-8. > Below mentioned 2 aliases are added as part of this:- > **ISO-8859-8-I** > **ISO8859-8-I** > > The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686 As the original bug submitter I might add that adding a mapping from ISO-8859-8-i to ISO-8859-8 is almost certainly correct and makes sense in the real world. The character encodings for ISO-8859-8 and ISO-8859-8-i charsets are exactly the same, and the distinction is only due to historical reasons. Email clients in the past did not "know about" right-to-left languages, instead the text was sent as regular ISO-8859-8 mail but sent line-by-line but with each line reversed. The reversed lines are displayed LTR (left-to-right) as-is. This is what's known as "visual ordering", and is required for old email clients. Newer email clients can do right-to-left, i.e. their text display engines started to support RTL display. So it was no longer necessary to send emails in "visual order" with reversed lines. But now there's a problem: how does the email client know whether the text is in "visual order" (displayed as-is LTR) or in "logical order" (displayed as RTL text). Thus ISO-8859-8-i was introduced. The charset decoding is exactly the same as ISO-8859-8, the only difference is in instructing the email client to display the lines not as-is LTR, but RTL. Old email clients cannot show these mails, as they do not know about ISO-8859-8-i and do not support RTL display anyways. The only drawback to adding the alias from ISO-8859-8-i to ISO-8859-8 is if you have a very old application (email client) that cannot do RTL display but used the newest JDK. Instead of showing an "unsupported charset" error it would then show the email but as LTR with each line reversed. I think that would be acceptable for almost everyone. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2354559575 From djelinski at openjdk.org Tue Sep 17 06:09:07 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 17 Sep 2024 06:09:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v8] In-Reply-To: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com> References: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com> Message-ID: On Fri, 13 Sep 2024 20:41:27 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Minor makefile tweak Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2308420140 From pminborg at openjdk.org Tue Sep 17 07:27:04 2024 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 17 Sep 2024 07:27:04 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v2] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 10:19:26 GMT, Kasper Nielsen wrote: > This would actually be super useful in a public API. I use the same "trick" in some of my projects. Not because I care too much about the classfile size. But it is just a lot easier on the eye. While I understand it would be convenient, there is a reason we have checked exceptions in the public APIs. Users can create similar utility methods in their projects if they want to "hide" the exceptions as you say. If you wish to add public methods anyhow, I think we should consider this under a separate issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2354746829 From liach at openjdk.org Tue Sep 17 12:20:10 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 17 Sep 2024 12:20:10 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v3] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 12:01:26 GMT, Per Minborg wrote: >> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. >> >> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: >> >> | Class File | Base [Bytes] | Patch [Byte] | >> | --------------------------------| ------------- | ------------ | >> | FutureTask.class | 10,255 | 10,123 | >> | AtomicBoolean.class | 5,364 | 5,134 | >> |AtomicMarkableReference.class | 3,890 | 3,660 | >> >> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) >> >> The new `MethodHandlesInternal.class` file is of size 1,952 bytes. >> >> In total for `java.base` we have: >> >> | Build map "jdk" | Size [Bytes] | >> | ---------------| ------------- | >> | Base | 5,906,457 | >> | Patch | 5,905,487 | >> | Delta | 940| >> >> For 60 billion instances, this represents > 50 TB. >> >> Tried and passed tier1-3 > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Move to new package and add overload > - Merge branch 'master' into internal-mh-util > - Rename and reformat > - Fix copyright headers > - Introduce MethodHandlesInternal I think the original poster means to find a VH in the lookup class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355564774 From duke at openjdk.org Tue Sep 17 12:37:05 2024 From: duke at openjdk.org (Kasper Nielsen) Date: Tue, 17 Sep 2024 12:37:05 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v3] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 12:17:06 GMT, Chen Liang wrote: > I think the original poster means to find a VH in the lookup class. I actually meant what Per is hinting at. Defining static MethodHandle/VarHandle in a class at class initialization time, without the ceremony of handling ReflectiveOperationException and throwing ExceptionInInitializerError. I could be mistaken but I think this is probably how most MethodHandle/VarHandles are defined. But I understand reason not to add these methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355614436 From alanb at openjdk.org Tue Sep 17 12:37:05 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 17 Sep 2024 12:37:05 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v2] In-Reply-To: References: Message-ID: <01ag0stjBVkfVciVp6EmsaprHkV2hyC67r1o5u6XHIY=.c519c314-5dd6-4768-9881-c2af7413abfc@github.com> On Tue, 17 Sep 2024 07:24:29 GMT, Per Minborg wrote: > If you wish to add public methods anyhow, I think we should consider this under a separate issue. I think it's a request for 10+ find methods to sit along the existing methods so it might be confusing too. I think your proposal looks generally okay, not sure about naming it "MethodHandlesInternal" with "internal" in the package name as it's more like a class of utility methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355617297 From pminborg at openjdk.org Tue Sep 17 12:59:13 2024 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 17 Sep 2024 12:59:13 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v3] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 12:01:26 GMT, Per Minborg wrote: >> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. >> >> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: >> >> | Class File | Base [Bytes] | Patch [Byte] | >> | --------------------------------| ------------- | ------------ | >> | FutureTask.class | 10,255 | 10,123 | >> | AtomicBoolean.class | 5,364 | 5,134 | >> |AtomicMarkableReference.class | 3,890 | 3,660 | >> >> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) >> >> The new `MethodHandlesInternal.class` file is of size 1,952 bytes. >> >> In total for `java.base` we have: >> >> | Build map "jdk" | Size [Bytes] | >> | ---------------| ------------- | >> | Base | 5,906,457 | >> | Patch | 5,905,487 | >> | Delta | 940| >> >> For 60 billion instances, this represents > 50 TB. >> >> Tried and passed tier1-3 > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Move to new package and add overload > - Merge branch 'master' into internal-mh-util > - Rename and reformat > - Fix copyright headers > - Introduce MethodHandlesInternal It is possible to create a project-specific utility method that can unwrap several methods like this: @FunctionalInterface public interface LookupFunction { R apply(MethodHandles.Lookup lookup, Class refc, String name, MethodType type) throws NoSuchMethodException, IllegalAccessException; } public static R unwrap(LookupFunction lookupFunction, MethodHandles.Lookup lookup, Class refc, String name, MethodType type) { try { return lookupFunction.apply(lookup, refc, name, type); } catch (ReflectiveOperationException e) { throw new InternalError(e); } } static final MethodHandle MH_SCALE = MethodHandlesUtil.unwrap(MethodHandles.Lookup::findVirtual, MethodHandles.lookup(), MemoryLayout.class, "scale", MethodType.methodType(long.class, long.class, long.class)); ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355690263 From pminborg at openjdk.org Tue Sep 17 13:05:24 2024 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 17 Sep 2024 13:05:24 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v4] In-Reply-To: References: Message-ID: > This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. > > While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: > > | Class File | Base [Bytes] | Patch [Byte] | > | --------------------------------| ------------- | ------------ | > | FutureTask.class | 10,255 | 10,123 | > | AtomicBoolean.class | 5,364 | 5,134 | > |AtomicMarkableReference.class | 3,890 | 3,660 | > > ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) > > The new `MethodHandlesInternal.class` file is of size 1,952 bytes. > > In total for `java.base` we have: > > | Build map "jdk" | Size [Bytes] | > | ---------------| ------------- | > | Base | 5,906,457 | > | Patch | 5,905,487 | > | Delta | 940| > > For 60 billion instances, this represents > 50 TB. > > Tried and passed tier1-3 Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Update javadoc - Rename utility class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20972/files - new: https://git.openjdk.org/jdk/pull/20972/files/e2e935b2..7f140322 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=02-03 Stats: 82 lines in 31 files changed: 0 ins; 0 del; 82 mod Patch: https://git.openjdk.org/jdk/pull/20972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972 PR: https://git.openjdk.org/jdk/pull/20972 From eirbjo at openjdk.org Tue Sep 17 13:37:05 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 17 Sep 2024 13:37:05 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v2] In-Reply-To: <01ag0stjBVkfVciVp6EmsaprHkV2hyC67r1o5u6XHIY=.c519c314-5dd6-4768-9881-c2af7413abfc@github.com> References: <01ag0stjBVkfVciVp6EmsaprHkV2hyC67r1o5u6XHIY=.c519c314-5dd6-4768-9881-c2af7413abfc@github.com> Message-ID: On Tue, 17 Sep 2024 12:33:34 GMT, Alan Bateman wrote: > I think your proposal looks generally okay, not sure about naming it "MethodHandlesInternal" with "internal" in the package name as it's more like a class of utility methods. Perhaps `MethodHandlesSupport`, like `jdk.internal.util.ArraysSupport`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355825352 From liach at openjdk.org Tue Sep 17 13:40:07 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 17 Sep 2024 13:40:07 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v4] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 13:05:24 GMT, Per Minborg wrote: >> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. >> >> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: >> >> | Class File | Base [Bytes] | Patch [Byte] | >> | --------------------------------| ------------- | ------------ | >> | FutureTask.class | 10,255 | 10,123 | >> | AtomicBoolean.class | 5,364 | 5,134 | >> |AtomicMarkableReference.class | 3,890 | 3,660 | >> >> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) >> >> The new `MethodHandlesInternal.class` file is of size 1,952 bytes. >> >> In total for `java.base` we have: >> >> | Build map "jdk" | Size [Bytes] | >> | ---------------| ------------- | >> | Base | 5,906,457 | >> | Patch | 5,905,487 | >> | Delta | 940| >> >> For 60 billion instances, this represents > 50 TB. >> >> Tried and passed tier1-3 > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Update javadoc > - Rename utility class I think a better approach to this problem might be converting these static final MethodHandle/VarHandle to class-file constants (Constant_MethodHandle for MH, Constant_Dynamic for VH), see JEP 303. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355833854 From rriggs at openjdk.org Tue Sep 17 14:07:05 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 17 Sep 2024 14:07:05 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v4] In-Reply-To: References: Message-ID: <3-8Pao_PVgev-cXH5tS4knP3CGHAgYbBsFf3hNc5ttY=.32535d56-044d-481d-8342-c44ed0811b91@github.com> On Tue, 17 Sep 2024 13:05:24 GMT, Per Minborg wrote: >> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. >> >> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: >> >> | Class File | Base [Bytes] | Patch [Byte] | >> | --------------------------------| ------------- | ------------ | >> | FutureTask.class | 10,255 | 10,123 | >> | AtomicBoolean.class | 5,364 | 5,134 | >> |AtomicMarkableReference.class | 3,890 | 3,660 | >> >> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) >> >> The new `MethodHandlesInternal.class` file is of size 1,952 bytes. >> >> In total for `java.base` we have: >> >> | Build map "jdk" | Size [Bytes] | >> | ---------------| ------------- | >> | Base | 5,906,457 | >> | Patch | 5,905,487 | >> | Delta | 940| >> >> For 60 billion instances, this represents > 50 TB. >> >> Tried and passed tier1-3 > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Update javadoc > - Rename utility class Overall looks good. Having a concise source construct representing these factories will enable jlink or similar pre-processing steps to optimize. The new class will be lonesome in its own package. I'd shorten the classname to "MHUtil" making the source lines more readable. src/java.base/share/classes/jdk/internal/invoke/MethodHandlesUtil.java line 35: > 33: /** > 34: * This class contains a number of static factories for certain > 35: * VarHandle/MethodHandle variants. I'd write this as a more concise 1st line comment. "This class contains a number of" is noise. "Utility static factories of method handles for fields and methods." or similar. ------------- PR Review: https://git.openjdk.org/jdk/pull/20972#pullrequestreview-2309856171 PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1763305393 From pminborg at openjdk.org Tue Sep 17 14:25:42 2024 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 17 Sep 2024 14:25:42 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v5] In-Reply-To: References: Message-ID: > This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. > > While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: > > | Class File | Base [Bytes] | Patch [Byte] | > | --------------------------------| ------------- | ------------ | > | FutureTask.class | 10,255 | 10,123 | > | AtomicBoolean.class | 5,364 | 5,134 | > |AtomicMarkableReference.class | 3,890 | 3,660 | > > ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) > > The new `MethodHandlesInternal.class` file is of size 1,952 bytes. > > In total for `java.base` we have: > > | Build map "jdk" | Size [Bytes] | > | ---------------| ------------- | > | Base | 5,906,457 | > | Patch | 5,905,487 | > | Delta | 940| > > For 60 billion instances, this represents > 50 TB. > > Tried and passed tier1-3 Per Minborg 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 nine additional commits since the last revision: - Merge branch 'master' into internal-mh-util - Rename class and shorten JavaDoc - Update javadoc - Rename utility class - Move to new package and add overload - Merge branch 'master' into internal-mh-util - Rename and reformat - Fix copyright headers - Introduce MethodHandlesInternal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20972/files - new: https://git.openjdk.org/jdk/pull/20972/files/7f140322..a1444c28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=03-04 Stats: 121988 lines in 261 files changed: 121641 ins; 172 del; 175 mod Patch: https://git.openjdk.org/jdk/pull/20972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972 PR: https://git.openjdk.org/jdk/pull/20972 From duke at openjdk.org Tue Sep 17 15:10:07 2024 From: duke at openjdk.org (David M. Lloyd) Date: Tue, 17 Sep 2024 15:10:07 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v4] In-Reply-To: References: Message-ID: <7988GQeBo-xYw7i-H9i6fTkQein298GVmZPJSgt1BIw=.773c89ab-ea3a-4c8c-9ae4-7817fb5bf744@github.com> On Tue, 17 Sep 2024 13:37:19 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update javadoc >> - Rename utility class > > I think a better approach to this problem might be converting these static final MethodHandle/VarHandle to class-file constants (Constant_MethodHandle for MH, Constant_Dynamic for VH), see JEP 303. In my projects I usually just use the `ConstantBootstraps` method directly, which avoids the try/catch (but does not avoid needing a lookup). In my mind I imagine eventually writing a tool which post-processes my classes and replaces all `private static final Xxx xxx = ConstantBootstraps.xxx()` with dynamic constants (similarly, I guess, to what @liach suggested). But maybe just using the existing `ConstantBootstraps` methods is a good stepping stone towards a JEP-303 kind of solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2356168738 From bpb at openjdk.org Tue Sep 17 15:53:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 17 Sep 2024 15:53:14 GMT Subject: Integrated: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) 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: On Thu, 31 Aug 2023 22:45:49 GMT, Brian Burkhalter wrote: > Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list. This pull request has now been integrated. Changeset: f8770163 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/f87701635f82895fc10586e588f25e9c508e6979 Stats: 26 lines in 3 files changed: 20 ins; 2 del; 4 mod 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) Reviewed-by: djelinski ------------- PR: https://git.openjdk.org/jdk/pull/15525 From jlu at openjdk.org Tue Sep 17 23:20:35 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 17 Sep 2024 23:20:35 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs Message-ID: Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. Primarily, usages where 'applet' is used interchangeably with 'application' are removed. This change does not include removal of usages in a historical sense. For example, something such as * @apiNote * Thread groups provided a way in early Java releases to group threads and provide * a form of job control for threads. Thread groups supported the isolation * of applets and defined methods intended for diagnostic purposes. It should be * rare for new applications to create ThreadGroups and interact with this API. in _src/java.base/share/classes/java/lang/ThreadGroup.java_. Please see the JBS issue comments for further reasoning on why other occurrences were not removed. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/21046/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21046&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339735 Stats: 17 lines in 7 files changed: 0 ins; 1 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/21046.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21046/head:pull/21046 PR: https://git.openjdk.org/jdk/pull/21046 From bpb at openjdk.org Tue Sep 17 23:42:31 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 17 Sep 2024 23:42:31 GMT Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win) Message-ID: Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link. ------------- Commit messages: - 8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win) Changes: https://git.openjdk.org/jdk/pull/21047/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21047&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340329 Stats: 52 lines in 2 files changed: 44 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/21047.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21047/head:pull/21047 PR: https://git.openjdk.org/jdk/pull/21047 From naoto at openjdk.org Tue Sep 17 23:50:06 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 17 Sep 2024 23:50:06 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs In-Reply-To: References: Message-ID: <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com> On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu wrote: > Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. > > Primarily, usages where 'applet' is used interchangeably with 'application' are removed. > This change does not include removal of usages in a historical sense. For example, something such as > > > * @apiNote > * Thread groups provided a way in early Java releases to group threads and provide > * a form of job control for threads. Thread groups supported the isolation > * of applets and defined methods intended for diagnostic purposes. It should be > * rare for new applications to create ThreadGroups and interact with this API. > > > in _src/java.base/share/classes/java/lang/ThreadGroup.java_. > Please see the JBS issue comments for further reasoning on why other occurrences were not removed. src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 74: > 72: volatile (or access to the variable must be > 73: synchronized).

> 74:

For example, suppose your application contains the following The example below is still applet specific (e.g., `repaint()`). May need to be more generic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764214361 From bpb at openjdk.org Tue Sep 17 23:55:04 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 17 Sep 2024 23:55:04 GMT Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win) In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 23:37:40 GMT, Brian Burkhalter wrote: > Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link. src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java line 308: > 306: String filename = null; > 307: try { > 308: filename = GetFinalPathNameByHandle(handle); One question is whether the string returned by `GetFinalPathNameByHandle` should be used as is, or converted to some other form. test/jdk/java/nio/file/Files/Links.java line 135: > 133: } > 134: > 135: // Check message of NotLinkException It might be that checking the message for just one single non-link, instead of both a file and a directory, is sufficient. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21047#discussion_r1764221658 PR Review Comment: https://git.openjdk.org/jdk/pull/21047#discussion_r1764222496 From alanb at openjdk.org Wed Sep 18 06:20:05 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Sep 2024 06:20:05 GMT Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win) In-Reply-To: References: Message-ID: <6Kw6Ru9SrYWI-LSJdF7KPFDb8FSsNIn-DZ1WJS5atI8=.bf89382e-4898-4dde-bb27-7d85a2b4a018@github.com> On Tue, 17 Sep 2024 23:50:29 GMT, Brian Burkhalter wrote: >> Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link. > > src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java line 308: > >> 306: String filename = null; >> 307: try { >> 308: filename = GetFinalPathNameByHandle(handle); > > One question is whether the string returned by `GetFinalPathNameByHandle` should be used as is, or converted to some other form. I think you just need to use the path that is passed to the readLink method, just pass it readLinkImpl. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21047#discussion_r1764461660 From coffeys at openjdk.org Wed Sep 18 06:28:05 2024 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 18 Sep 2024 06:28:05 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs In-Reply-To: <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com> References: <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com> Message-ID: On Tue, 17 Sep 2024 23:36:16 GMT, Naoto Sato wrote: >> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. >> >> Primarily, usages where 'applet' is used interchangeably with 'application' are removed. >> This change does not include removal of usages in a historical sense. For example, something such as >> >> >> * @apiNote >> * Thread groups provided a way in early Java releases to group threads and provide >> * a form of job control for threads. Thread groups supported the isolation >> * of applets and defined methods intended for diagnostic purposes. It should be >> * rare for new applications to create ThreadGroups and interact with this API. >> >> >> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. >> Please see the JBS issue comments for further reasoning on why other occurrences were not removed. > > src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 74: > >> 72: volatile (or access to the variable must be >> 73: synchronized).

>> 74:

For example, suppose your application contains the following > > The example below is still applet specific (e.g., `repaint()`). May need to be more generic. `repaint()` could be substituted with another arbitrary method name to highlight some work this thread has to perform. given the thread name `blink`, perhaps we could just use `blink()` in this example. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764469513 From alanb at openjdk.org Wed Sep 18 06:56:06 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Sep 2024 06:56:06 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs In-Reply-To: References: <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com> Message-ID: <8TE8V8dQSm8L8BRmW3hnAUmK36L_hfUZlIcglIHr9r0=.6437c81a-0b29-43d0-94ed-434c5feb730e@github.com> On Wed, 18 Sep 2024 06:25:57 GMT, Sean Coffey wrote: >> src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 74: >> >>> 72: volatile (or access to the variable must be >>> 73: synchronized).

>>> 74:

For example, suppose your application contains the following >> >> The example below is still applet specific (e.g., `repaint()`). May need to be more generic. > > `repaint()` could be substituted with another arbitrary method name to highlight some work this thread has to perform. > > given the thread name `blink`, perhaps we could just use `blink()` in this example. Don't waste too much time on the "Java Thread Primitive Deprecation" page. The last remnant is the no-arg Thread.stop method which throws UOE unconditionally. Once that is removed then the doc-file pages will be removed too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764497660 From alanb at openjdk.org Wed Sep 18 06:56:07 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Sep 2024 06:56:07 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu wrote: > Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. > > Primarily, usages where 'applet' is used interchangeably with 'application' are removed. > This change does not include removal of usages in a historical sense. For example, something such as > > > * @apiNote > * Thread groups provided a way in early Java releases to group threads and provide > * a form of job control for threads. Thread groups supported the isolation > * of applets and defined methods intended for diagnostic purposes. It should be > * rare for new applications to create ThreadGroups and interact with this API. > > > in _src/java.base/share/classes/java/lang/ThreadGroup.java_. > Please see the JBS issue comments for further reasoning on why other occurrences were not removed. src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 39: > 37: * implementation classes. Charset providers may be installed in an instance > 38: * of the Java platform as extensions. Providers may also be made available by > 39: * adding them to the application class path or by some other They can also be deployed on the application module path, maybe need a separate JBS issue to clarify that part of the spec, and add a test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764498846 From duke at openjdk.org Wed Sep 18 08:01:18 2024 From: duke at openjdk.org (Pratiksha.Sawant) Date: Wed, 18 Sep 2024 08:01:18 GMT Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded, should be mapped to ISO-8859-8 In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant wrote: > Mapping ISO-8859-8-I charset to ISO-8859-8. > Below mentioned 2 aliases are added as part of this:- > **ISO-8859-8-I** > **ISO8859-8-I** > > The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686 Based on our analysis, we've identified that the file ?EncodingMap.java? includes an entry where "ISO-8859-8-I" is defined as an alias for "ISO8859_8." This entry is found in the headstream repository, and we believe it makes sense to include this in the charsets file as well. You can reference the relevant section here: [EncodingMap.java](https://github.com/openjdk/jdk/blob/5381f553ad61ddaa44d49c3039a05511cc68bdd0/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java#L770). Moreover, the original bug submitter has expressed agreement with our proposed solution, as noted in the discussion [here](https://github.com/openjdk/jdk/pull/20690#issuecomment-2354559575). If we decide to create a new charset mapping for "ISO-8859-8-I," it would essentially mirror "ISO-8859-8," differing only in the naming convention. This would function similarly to creating an alias in the charsets file. Therefore, we propose that this approach is valid and appropriate for implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2357768469 From mullan at openjdk.org Wed Sep 18 13:02:05 2024 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 18 Sep 2024 13:02:05 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu wrote: > Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. > > Primarily, usages where 'applet' is used interchangeably with 'application' are removed. > This change does not include removal of usages in a historical sense. For example, something such as > > > * @apiNote > * Thread groups provided a way in early Java releases to group threads and provide > * a form of job control for threads. Thread groups supported the isolation > * of applets and defined methods intended for diagnostic purposes. It should be > * rare for new applications to create ThreadGroups and interact with this API. > > > in _src/java.base/share/classes/java/lang/ThreadGroup.java_. > Please see the JBS issue comments for further reasoning on why other occurrences were not removed. src/java.base/share/classes/javax/net/SocketFactory.java line 63: > 61: *

Factory classes are specified by environment-specific configuration > 62: * mechanisms. For example, the getDefault method could return > 63: * a factory that was appropriate for a particular user, and a Suggest changing this to "particular application" instead of "particular user" as it seems a bit odd to be talking about users here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1765011733 From bpb at openjdk.org Wed Sep 18 15:54:07 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Sep 2024 15:54:07 GMT Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win) In-Reply-To: <6Kw6Ru9SrYWI-LSJdF7KPFDb8FSsNIn-DZ1WJS5atI8=.bf89382e-4898-4dde-bb27-7d85a2b4a018@github.com> References: <6Kw6Ru9SrYWI-LSJdF7KPFDb8FSsNIn-DZ1WJS5atI8=.bf89382e-4898-4dde-bb27-7d85a2b4a018@github.com> Message-ID: <9tSBtQPK61nw2GgnzbzFOqpa1HOIHvvwt1EX3mwNQuU=.d25a0b61-d100-418a-a950-62482cf36de0@github.com> On Wed, 18 Sep 2024 06:17:12 GMT, Alan Bateman wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java line 308: >> >>> 306: String filename = null; >>> 307: try { >>> 308: filename = GetFinalPathNameByHandle(handle); >> >> One question is whether the string returned by `GetFinalPathNameByHandle` should be used as is, or converted to some other form. > > I think you just need to use the path that is passed to the readLink method, just pass it readLinkImpl. I agree. What I did was lame. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21047#discussion_r1765317556 From bpb at openjdk.org Wed Sep 18 16:20:25 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Sep 2024 16:20:25 GMT Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win) [v2] In-Reply-To: References: Message-ID: <8PleEftjQAWyxrJ2WerTeC90aJxo5JaZc2ikkz4tFxk=.80fd0ad6-25f5-4d6b-8974-b9d8c666bfeb@github.com> > Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8340329: Pass the path into readLinkImpl instead of calling GetFinalPathNameByHandle ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21047/files - new: https://git.openjdk.org/jdk/pull/21047/files/a1b7e2d0..a117766b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21047&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21047&range=00-01 Stats: 33 lines in 2 files changed: 2 ins; 23 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/21047.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21047/head:pull/21047 PR: https://git.openjdk.org/jdk/pull/21047 From alanb at openjdk.org Wed Sep 18 17:41:04 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Sep 2024 17:41:04 GMT Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win) [v2] In-Reply-To: <8PleEftjQAWyxrJ2WerTeC90aJxo5JaZc2ikkz4tFxk=.80fd0ad6-25f5-4d6b-8974-b9d8c666bfeb@github.com> References: <8PleEftjQAWyxrJ2WerTeC90aJxo5JaZc2ikkz4tFxk=.80fd0ad6-25f5-4d6b-8974-b9d8c666bfeb@github.com> Message-ID: On Wed, 18 Sep 2024 16:20:25 GMT, Brian Burkhalter wrote: >> Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8340329: Pass the path into readLinkImpl instead of calling GetFinalPathNameByHandle Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21047#pullrequestreview-2313356574 From jlu at openjdk.org Wed Sep 18 17:59:40 2024 From: jlu at openjdk.org (Justin Lu) Date: Wed, 18 Sep 2024 17:59:40 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2] In-Reply-To: References: Message-ID: > Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. > > Primarily, usages where 'applet' is used interchangeably with 'application' are removed. > This change does not include removal of usages in a historical sense. For example, something such as > > > * @apiNote > * Thread groups provided a way in early Java releases to group threads and provide > * a form of job control for threads. Thread groups supported the isolation > * of applets and defined methods intended for diagnostic purposes. It should be > * rare for new applications to create ThreadGroups and interact with this API. > > > in _src/java.base/share/classes/java/lang/ThreadGroup.java_. > Please see the JBS issue comments for further reasoning on why other occurrences were not removed. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21046/files - new: https://git.openjdk.org/jdk/pull/21046/files/731e4ee1..19d6b725 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21046&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21046&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21046.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21046/head:pull/21046 PR: https://git.openjdk.org/jdk/pull/21046 From jlu at openjdk.org Wed Sep 18 17:59:40 2024 From: jlu at openjdk.org (Justin Lu) Date: Wed, 18 Sep 2024 17:59:40 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2] In-Reply-To: <8TE8V8dQSm8L8BRmW3hnAUmK36L_hfUZlIcglIHr9r0=.6437c81a-0b29-43d0-94ed-434c5feb730e@github.com> References: <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com> <8TE8V8dQSm8L8BRmW3hnAUmK36L_hfUZlIcglIHr9r0=.6437c81a-0b29-43d0-94ed-434c5feb730e@github.com> Message-ID: On Wed, 18 Sep 2024 06:52:17 GMT, Alan Bateman wrote: >> `repaint()` could be substituted with another arbitrary method name to highlight some work this thread has to perform. >> >> given the thread name `blink`, perhaps we could just use `blink()` in this example. > > Don't waste too much time on the "Java Thread Primitive Deprecation" page. The last remnant is the no-arg Thread.stop method which throws UOE unconditionally. Once that is removed then the doc-file pages will be removed too. Kept it simple and simply replaced with Sean's suggestion of `blink()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1765481816 From jlu at openjdk.org Wed Sep 18 17:59:41 2024 From: jlu at openjdk.org (Justin Lu) Date: Wed, 18 Sep 2024 17:59:41 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 06:53:27 GMT, Alan Bateman wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect review comments > > src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 39: > >> 37: * implementation classes. Charset providers may be installed in an instance >> 38: * of the Java platform as extensions. Providers may also be made available by >> 39: * adding them to the application class path or by some other > > They can also be deployed on the application module path, maybe need a separate JBS issue to clarify that part of the spec, and add a test. Filed https://bugs.openjdk.org/browse/JDK-8340404 to handle this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1765481753 From coffeys at openjdk.org Wed Sep 18 18:27:05 2024 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 18 Sep 2024 18:27:05 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. >> >> Primarily, usages where 'applet' is used interchangeably with 'application' are removed. >> This change does not include removal of usages in a historical sense. For example, something such as >> >> >> * @apiNote >> * Thread groups provided a way in early Java releases to group threads and provide >> * a form of job control for threads. Thread groups supported the isolation >> * of applets and defined methods intended for diagnostic purposes. It should be >> * rare for new applications to create ThreadGroups and interact with this API. >> >> >> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. >> Please see the JBS issue comments for further reasoning on why other occurrences were not removed. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review comments Marked as reviewed by coffeys (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313447275 From naoto at openjdk.org Wed Sep 18 19:57:04 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 18 Sep 2024 19:57:04 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. >> >> Primarily, usages where 'applet' is used interchangeably with 'application' are removed. >> This change does not include removal of usages in a historical sense. For example, something such as >> >> >> * @apiNote >> * Thread groups provided a way in early Java releases to group threads and provide >> * a form of job control for threads. Thread groups supported the isolation >> * of applets and defined methods intended for diagnostic purposes. It should be >> * rare for new applications to create ThreadGroups and interact with this API. >> >> >> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. >> Please see the JBS issue comments for further reasoning on why other occurrences were not removed. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review comments LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313649127 From iris at openjdk.org Wed Sep 18 20:28:01 2024 From: iris at openjdk.org (Iris Clark) Date: Wed, 18 Sep 2024 20:28:01 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. >> >> Primarily, usages where 'applet' is used interchangeably with 'application' are removed. >> This change does not include removal of usages in a historical sense. For example, something such as >> >> >> * @apiNote >> * Thread groups provided a way in early Java releases to group threads and provide >> * a form of job control for threads. Thread groups supported the isolation >> * of applets and defined methods intended for diagnostic purposes. It should be >> * rare for new applications to create ThreadGroups and interact with this API. >> >> >> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. >> Please see the JBS issue comments for further reasoning on why other occurrences were not removed. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review comments Happy to see us getting one step closer to removing Applets. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313706558 From rriggs at openjdk.org Wed Sep 18 20:48:41 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 18 Sep 2024 20:48:41 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. >> >> Primarily, usages where 'applet' is used interchangeably with 'application' are removed. >> This change does not include removal of usages in a historical sense. For example, something such as >> >> >> * @apiNote >> * Thread groups provided a way in early Java releases to group threads and provide >> * a form of job control for threads. Thread groups supported the isolation >> * of applets and defined methods intended for diagnostic purposes. It should be >> * rare for new applications to create ThreadGroups and interact with this API. >> >> >> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. >> Please see the JBS issue comments for further reasoning on why other occurrences were not removed. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review comments LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313767821 From lancea at openjdk.org Wed Sep 18 21:01:43 2024 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 18 Sep 2024 21:01:43 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. >> >> Primarily, usages where 'applet' is used interchangeably with 'application' are removed. >> This change does not include removal of usages in a historical sense. For example, something such as >> >> >> * @apiNote >> * Thread groups provided a way in early Java releases to group threads and provide >> * a form of job control for threads. Thread groups supported the isolation >> * of applets and defined methods intended for diagnostic purposes. It should be >> * rare for new applications to create ThreadGroups and interact with this API. >> >> >> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. >> Please see the JBS issue comments for further reasoning on why other occurrences were not removed. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review comments Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313789102 From jlu at openjdk.org Thu Sep 19 00:13:05 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 19 Sep 2024 00:13:05 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path Message-ID: Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. This came as a result from a comment on the PR of JDK-8339735. I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. ------------- Commit messages: - newline in module-info.java - init Changes: https://git.openjdk.org/jdk/pull/21076/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340404 Stats: 149 lines in 4 files changed: 139 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/21076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21076/head:pull/21076 PR: https://git.openjdk.org/jdk/pull/21076 From alanb at openjdk.org Thu Sep 19 05:43:39 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 19 Sep 2024 05:43:39 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path In-Reply-To: References: Message-ID: <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com> On Thu, 19 Sep 2024 00:07:30 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. > > This came as a result from a comment on the PR of JDK-8339735. > > I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. > > An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. test/jdk/java/nio/charset/spi/CharsetProviderAsModuleTest.java line 45: > 43: } else { > 44: bazCs = cs.get("BAZ"); > 45: var aliases = bazCs.aliases(); I think this needs to test that bazCs.getClass().getModule() is a named module. test/jdk/java/nio/charset/spi/provider/module-info.java line 24: > 22: */ > 23: module provider { > 24: exports spi; It's a bit of anti pattern for service provider modules to export an API, can you drop this? I don't think it's possible to check the test setup while that is there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1766189848 PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1766188958 From alanb at openjdk.org Thu Sep 19 05:51:42 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 19 Sep 2024 05:51:42 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path In-Reply-To: References: Message-ID: <9WJ7po2vi2C27VDTtEd4Sba-F_k9co56B6_fciZ5t7U=.0c85e8a3-5c90-4577-b95a-343514ad8269@github.com> On Thu, 19 Sep 2024 00:07:30 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. > > This came as a result from a comment on the PR of JDK-8339735. > > I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. > > An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. test/jdk/java/nio/charset/spi/CharsetProviderAsModuleTest.java line 28: > 26: * @bug 8340404 > 27: * @summary Check that a CharsetProvider SPI can be deployed as a module > 28: * @modules provider The `@modules` tag is used for test selection, I don't know what L28 does. test/jdk/java/nio/charset/spi/CharsetProviderAsModuleTest.java line 29: > 27: * @summary Check that a CharsetProvider SPI can be deployed as a module > 28: * @modules provider > 29: * @build provider/module-info provider/spi.BazProvider You can use `@build provider/*` here and jtreg will do the right thing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1766196688 PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1766195932 From mullan at openjdk.org Thu Sep 19 11:47:37 2024 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 19 Sep 2024 11:47:37 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. >> >> Primarily, usages where 'applet' is used interchangeably with 'application' are removed. >> This change does not include removal of usages in a historical sense. For example, something such as >> >> >> * @apiNote >> * Thread groups provided a way in early Java releases to group threads and provide >> * a form of job control for threads. Thread groups supported the isolation >> * of applets and defined methods intended for diagnostic purposes. It should be >> * rare for new applications to create ThreadGroups and interact with this API. >> >> >> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. >> Please see the JBS issue comments for further reasoning on why other occurrences were not removed. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review comments Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2315289461 From bpb at openjdk.org Thu Sep 19 15:27:40 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 19 Sep 2024 15:27:40 GMT Subject: Integrated: 8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win) In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 23:37:40 GMT, Brian Burkhalter wrote: > Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link. This pull request has now been integrated. Changeset: 2ada313c Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/2ada313cdd9a20ed33f7e0a7298c8a0e69a81c6f Stats: 34 lines in 2 files changed: 23 ins; 0 del; 11 mod 8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win) Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/21047 From jlu at openjdk.org Thu Sep 19 16:21:43 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 19 Sep 2024 16:21:43 GMT Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs [v2] In-Reply-To: References: Message-ID: <8vbEWScGpsDLSyqFV_wVIsJOGtYFHIvXVGOqh5n0pUA=.3faedb46-eed4-43b9-8ad8-435ba8f320e2@github.com> On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote: >> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. >> >> Primarily, usages where 'applet' is used interchangeably with 'application' are removed. >> This change does not include removal of usages in a historical sense. For example, something such as >> >> >> * @apiNote >> * Thread groups provided a way in early Java releases to group threads and provide >> * a form of job control for threads. Thread groups supported the isolation >> * of applets and defined methods intended for diagnostic purposes. It should be >> * rare for new applications to create ThreadGroups and interact with this API. >> >> >> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. >> Please see the JBS issue comments for further reasoning on why other occurrences were not removed. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review comments Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21046#issuecomment-2361455381 From jlu at openjdk.org Thu Sep 19 16:21:43 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 19 Sep 2024 16:21:43 GMT Subject: Integrated: 8339735: Remove references to Applet in core-libs/security APIs In-Reply-To: References: Message-ID: <4Jni6WhPBSkweDV1MOhkafn9oCwETZ4Ly2Z5qmr9ZB4=.5c7f9170-82a1-478f-85bb-1f6f60b945bb@github.com> On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu wrote: > Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation. > > Primarily, usages where 'applet' is used interchangeably with 'application' are removed. > This change does not include removal of usages in a historical sense. For example, something such as > > > * @apiNote > * Thread groups provided a way in early Java releases to group threads and provide > * a form of job control for threads. Thread groups supported the isolation > * of applets and defined methods intended for diagnostic purposes. It should be > * rare for new applications to create ThreadGroups and interact with this API. > > > in _src/java.base/share/classes/java/lang/ThreadGroup.java_. > Please see the JBS issue comments for further reasoning on why other occurrences were not removed. This pull request has now been integrated. Changeset: 5f3e7aa8 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/5f3e7aa83348edafb83480ce67d0c58c46e11b24 Stats: 19 lines in 7 files changed: 0 ins; 1 del; 18 mod 8339735: Remove references to Applet in core-libs/security APIs Reviewed-by: coffeys, naoto, iris, rriggs, lancea, mullan ------------- PR: https://git.openjdk.org/jdk/pull/21046 From jlu at openjdk.org Thu Sep 19 16:55:49 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 19 Sep 2024 16:55:49 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v2] In-Reply-To: References: Message-ID: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. > > This came as a result from a comment on the PR of JDK-8339735. > > I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. > > An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - merge master, resolve conflicts - reflect review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21076/files - new: https://git.openjdk.org/jdk/pull/21076/files/a9cb9db1..6aff4f3f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=00-01 Stats: 1651 lines in 75 files changed: 1360 ins; 36 del; 255 mod Patch: https://git.openjdk.org/jdk/pull/21076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21076/head:pull/21076 PR: https://git.openjdk.org/jdk/pull/21076 From jlu at openjdk.org Thu Sep 19 17:03:02 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 19 Sep 2024 17:03:02 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v3] In-Reply-To: References: Message-ID: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. > > This came as a result from a comment on the PR of JDK-8339735. > > I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. > > An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - resolve conflicts; list deployment as module first - merge master, resolve conflicts - reflect review comments - newline in module-info.java - init ------------- Changes: https://git.openjdk.org/jdk/pull/21076/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=02 Stats: 154 lines in 4 files changed: 145 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/21076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21076/head:pull/21076 PR: https://git.openjdk.org/jdk/pull/21076 From naoto at openjdk.org Thu Sep 19 17:03:02 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 19 Sep 2024 17:03:02 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v3] In-Reply-To: References: Message-ID: <7yNQ7OyM4lcRBPGSr0xtMR3GQWXMS6GObAH_cMBfPQY=.135d687e-8b1e-4b01-a5f8-fd23a13f1c4c@github.com> On Thu, 19 Sep 2024 16:59:50 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. >> >> This came as a result from a comment on the PR of JDK-8339735. >> >> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. >> >> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - resolve conflicts; list deployment as module first > - merge master, resolve conflicts > - reflect review comments > - newline in module-info.java > - init src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 38: > 36: * zero-argument constructor and some number of associated charset > 37: * implementation classes. Charset providers may be installed in an instance > 38: * of the Java platform as extensions. Providers may also be made available by It is not related to module path, but taking this opportunity, let's amend this sentence that refers to "extensions" which is obsolete. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1767244764 From jlu at openjdk.org Thu Sep 19 17:03:02 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 19 Sep 2024 17:03:02 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v3] In-Reply-To: <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com> References: <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com> Message-ID: On Thu, 19 Sep 2024 05:39:39 GMT, Alan Bateman wrote: >> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - resolve conflicts; list deployment as module first >> - merge master, resolve conflicts >> - reflect review comments >> - newline in module-info.java >> - init > > test/jdk/java/nio/charset/spi/provider/module-info.java line 24: > >> 22: */ >> 23: module provider { >> 24: exports spi; > > It's a bit of anti pattern for service provider modules to export an API, can you drop this? I don't think it's possible to check the test setup while that is there. Thanks for taking a look Alan. Your test comments should be addressed in https://github.com/openjdk/jdk/pull/21076/commits/790abd039dd08ca1e0575feca29f681a2507d902. Did you have any comments on the current doc change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1767246756 From jlu at openjdk.org Thu Sep 19 17:05:49 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 19 Sep 2024 17:05:49 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v4] In-Reply-To: References: Message-ID: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. > > This came as a result from a comment on the PR of JDK-8339735. > > I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. > > An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: drop obsolete 'extensions' sentence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21076/files - new: https://git.openjdk.org/jdk/pull/21076/files/13626924..b7b5044f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21076/head:pull/21076 PR: https://git.openjdk.org/jdk/pull/21076 From pminborg at openjdk.org Fri Sep 20 07:28:40 2024 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 20 Sep 2024 07:28:40 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v5] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 14:25:42 GMT, Per Minborg wrote: >> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. >> >> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: >> >> | Class File | Base [Bytes] | Patch [Byte] | >> | --------------------------------| ------------- | ------------ | >> | FutureTask.class | 10,255 | 10,123 | >> | AtomicBoolean.class | 5,364 | 5,134 | >> |AtomicMarkableReference.class | 3,890 | 3,660 | >> >> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) >> >> The new `MethodHandlesInternal.class` file is of size 1,952 bytes. >> >> In total for `java.base` we have: >> >> | Build map "jdk" | Size [Bytes] | >> | ---------------| ------------- | >> | Base | 5,906,457 | >> | Patch | 5,905,487 | >> | Delta | 940| >> >> For 60 billion instances, this represents > 50 TB. >> >> Tried and passed tier1-3 > > Per Minborg 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 nine additional commits since the last revision: > > - Merge branch 'master' into internal-mh-util > - Rename class and shorten JavaDoc > - Update javadoc > - Rename utility class > - Move to new package and add overload > - Merge branch 'master' into internal-mh-util > - Rename and reformat > - Fix copyright headers > - Introduce MethodHandlesInternal I've experimented a bit with using the `ConstantBoostraps::fieldVarHandle` method and here is what it looks like at a call site (example from `CompletableFuture`): RESULT = ConstantBootstraps.fieldVarHandle(l, "result", VarHandle.class, CompletableFuture.class, Object.class); Compared to: RESULT = MhUtil.findVarHandle(l, "result", Object.class); One advantage is that we can remove two methods from the `MhUtil` class but the drawback is we need to add a lot of more parameters at the call sites. Eventually, both methods will work the same except from the exception handling. So, I think it is better to use the proposed `MhUtil` rather than `ConstantBootstraps`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2363013810 From pminborg at openjdk.org Fri Sep 20 07:36:18 2024 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 20 Sep 2024 07:36:18 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v6] In-Reply-To: References: Message-ID: > This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. > > While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: > > | Class File | Base [Bytes] | Patch [Byte] | > | --------------------------------| ------------- | ------------ | > | FutureTask.class | 10,255 | 10,123 | > | AtomicBoolean.class | 5,364 | 5,134 | > |AtomicMarkableReference.class | 3,890 | 3,660 | > > ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) > > The new `MethodHandlesInternal.class` file is of size 1,952 bytes. > > In total for `java.base` we have: > > | Build map "jdk" | Size [Bytes] | > | ---------------| ------------- | > | Base | 5,906,457 | > | Patch | 5,905,487 | > | Delta | 940| > > For 60 billion instances, this represents > 50 TB. > > Tried and passed tier1-3 Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Simplify calls - Merge branch 'master' into internal-mh-util - Merge branch 'master' into internal-mh-util - Rename class and shorten JavaDoc - Update javadoc - Rename utility class - Move to new package and add overload - Merge branch 'master' into internal-mh-util - Rename and reformat - Fix copyright headers - ... and 1 more: https://git.openjdk.org/jdk/compare/85e28c70...5d9f1be9 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20972/files - new: https://git.openjdk.org/jdk/pull/20972/files/a1444c28..5d9f1be9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=04-05 Stats: 20508 lines in 294 files changed: 18484 ins; 277 del; 1747 mod Patch: https://git.openjdk.org/jdk/pull/20972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972 PR: https://git.openjdk.org/jdk/pull/20972 From pminborg at openjdk.org Fri Sep 20 08:14:04 2024 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 20 Sep 2024 08:14:04 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v7] In-Reply-To: References: Message-ID: > This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. > > While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: > > | Class File | Base [Bytes] | Patch [Byte] | > | --------------------------------| ------------- | ------------ | > | FutureTask.class | 10,255 | 10,123 | > | AtomicBoolean.class | 5,364 | 5,134 | > |AtomicMarkableReference.class | 3,890 | 3,660 | > > ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) > > The new `MethodHandlesInternal.class` file is of size 1,952 bytes. > > In total for `java.base` we have: > > | Build map "jdk" | Size [Bytes] | > | ---------------| ------------- | > | Base | 5,906,457 | > | Patch | 5,905,487 | > | Delta | 940| > > For 60 billion instances, this represents > 50 TB. > > Tried and passed tier1-3 Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Revert change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20972/files - new: https://git.openjdk.org/jdk/pull/20972/files/5d9f1be9..67f90de7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972 PR: https://git.openjdk.org/jdk/pull/20972 From duke at openjdk.org Fri Sep 20 11:52:35 2024 From: duke at openjdk.org (xpbob) Date: Fri, 20 Sep 2024 11:52:35 GMT Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed message for NoSuchFileException [v2] In-Reply-To: References: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com> Message-ID: <8mVK7spKMbxnKn6pp4IWnE9CELvHUUDuSYVrZTOxzi8=.875b39a2-584e-4064-8ec9-c2064e4de2fb@github.com> On Fri, 13 Sep 2024 07:19:11 GMT, Alan Bateman wrote: >> xpbob has updated the pull request incrementally with one additional commit since the last revision: >> >> Reimport package > > src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1013: > >> 1011: if (symbolicLink != null) { >> 1012: throw new NoSuchFileException(source.toString(), null, "due to " + symbolicLink); >> 1013: } > > The default provider implementation can't use Files.* methods, otherwise you end up with recursive usage. > > In any case, I think the starting out to decide if anything should change as the existing NoSuchFileException is not wrong. @AlanBateman @bplb sorry for late,Thanks for guiding the process ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20984#discussion_r1768462153 From alanb at openjdk.org Fri Sep 20 13:01:39 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 20 Sep 2024 13:01:39 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v4] In-Reply-To: References: <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com> Message-ID: On Thu, 19 Sep 2024 16:59:50 GMT, Justin Lu wrote: > Did you have any comments on the current doc change? I've been slow to reply on that because I'm not 100% sure if the spec is correct. Can you double check that the CCL is actually used. I think it uses the system class loader, and maybe the platform class loader for the extended charsets. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1768577156 From alanb at openjdk.org Fri Sep 20 13:09:36 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 20 Sep 2024 13:09:36 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v4] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 17:05:49 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. >> >> This came as a result from a comment on the PR of JDK-8339735. >> >> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. >> >> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > drop obsolete 'extensions' sentence src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 43: > 41: * loader}. See {@link java.util.ServiceLoader##developing-service-providers > 42: * Deploying Service Providers} for further detail on deploying a charset > 43: * provider as a module or on the class path. I think it would better to say "deployed" rather than "available" here, that will align with the later text. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1768587575 From rriggs at openjdk.org Fri Sep 20 16:14:38 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 20 Sep 2024 16:14:38 GMT Subject: RFR: 8325949: Create an internal utility method for creating VarHandle instances [v7] In-Reply-To: References: Message-ID: <7MJxg_rS9YTysPR7WLIMT7SF__DNazV5DtgNqh0goyU=.3117eb70-70aa-4029-90c3-432175c5aece@github.com> On Fri, 20 Sep 2024 08:14:04 GMT, Per Minborg wrote: >> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. >> >> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: >> >> | Class File | Base [Bytes] | Patch [Byte] | >> | --------------------------------| ------------- | ------------ | >> | FutureTask.class | 10,255 | 10,123 | >> | AtomicBoolean.class | 5,364 | 5,134 | >> |AtomicMarkableReference.class | 3,890 | 3,660 | >> >> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) >> >> The new `MethodHandlesInternal.class` file is of size 1,952 bytes. >> >> In total for `java.base` we have: >> >> | Build map "jdk" | Size [Bytes] | >> | ---------------| ------------- | >> | Base | 5,906,457 | >> | Patch | 5,905,487 | >> | Delta | 940| >> >> For 60 billion instances, this represents > 50 TB. >> >> Tried and passed tier1-3 > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Revert change Looks good. The current (MhUtil) source is easier to read. So unless ConstantBootstraps could have an equivalent (simple) API that evaluates to a DynamicConstant, keep what you have. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20972#pullrequestreview-2318714294 PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2364070043 From dhanalla at openjdk.org Fri Sep 20 22:14:40 2024 From: dhanalla at openjdk.org (Dhamoder Nalla) Date: Fri, 20 Sep 2024 22:14:40 GMT Subject: RFR: 8338858: Replace undocumented APIs with documented APIs in the OpenJDK In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 18:18:57 GMT, Dhamoder Nalla wrote: > The `wepoll` code has been ported from opensource repo [`wepoll`](https://github.com/piscisaureus/wepoll) to OpenJDK in PR [pull/3816](https://github.com/openjdk/jdk/pull/3816), which incorporated undocumented Windows APIs (NtCreateKeyedEvent, NtReleaseKeyedEvent, NtWaitForKeyedEvent). > > This PR aims to replace these undocumented APIs with documented synchronization APIs. > > Test Performed: > 1. All 12 tests in wepoll repo passed > test-auto-drop-on-close PASS > test-connect-fail-events PASS > test-connect-success-events PASS > test-ctl-fuzz PASS > test-error PASS > test-leak-1 PASS > test-mixed-socket-types PASS > test-multi-poll PASS > test-oneshot-and-hangup PASS > test-reflock PASS > test-tree PASS > test-udp-pings PASS > DONE - 12 PASSED, 0 FAILED > > 2. No new failure in JTreg test > 3. Micro bench results: similar performance score before and after the changes > > without change in this PR: > > ![image](https://github.com/user-attachments/assets/c784d00e-3f0a-483d-b60a-c7a46aba885c) > > With the change in this PR: > > ![image](https://github.com/user-attachments/assets/5e6a68bc-48ae-475f-891e-395941068f6e) > I understand that this is a like-for-like replacement, where `reflock__signal_event` waits for another thread to call `reflock__await_event`, because that's what `NtReleaseKeyedEvent` did, even if that is not necessary from the perspective of the calling code. It looks OK, but it doesn't make the code easier to follow. > > I think if we're going to touch this code, we should make it more readable than the original. We could replace the whole reflock structure with SRW locks; `reflock_ref` is semantically equivalent to `AcquireSRWLockShared`, `reflock_unref` is equivalent to `ReleaseSRWLockShared`, and `reflock_unref_and_destroy` is equivalent to `ReleaseSRWLockShared` followed by `AcquireSRWLockExclusive`. > > Also, I'd very much like to avoid forking wepoll here. We keep our own copy to simplify the build system, but we don't want to maintain our own fork. @dhanalla if the [piscisaureus/wepoll#37](https://github.com/piscisaureus/wepoll/pull/37) request is not accepted, do you plan to maintain a fork of wepoll? Or is wepoll officially dead? > > Finally, this PR claims to replace the undocumented APIs, but does nothing about the usage of AFD. Is there a plan to remove the AFD too? Thank you @djelinski, At this time, we don?t have the bandwidth to fork and maintain wepoll. If this presents a challenge for the PR, we completely understand and will proceed by closing it. We will make the necessary changes directly in our downstream distribution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20682#issuecomment-2364687200 From jlu at openjdk.org Fri Sep 20 23:41:10 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 20 Sep 2024 23:41:10 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v5] In-Reply-To: References: Message-ID: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. > > This came as a result from a comment on the PR of JDK-8339735. > > I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. > > An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: review: 'available' -> 'deployed' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21076/files - new: https://git.openjdk.org/jdk/pull/21076/files/b7b5044f..c4056ba8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21076/head:pull/21076 PR: https://git.openjdk.org/jdk/pull/21076 From jlu at openjdk.org Fri Sep 20 23:41:11 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 20 Sep 2024 23:41:11 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 13:07:05 GMT, Alan Bateman wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> drop obsolete 'extensions' sentence > > src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 43: > >> 41: * loader}. See {@link java.util.ServiceLoader##developing-service-providers >> 42: * Deploying Service Providers} for further detail on deploying a charset >> 43: * provider as a module or on the class path. > > I think it would better to say "deployed" rather than "available" here, that will align with the later text. I presume you meant the "available" on line 37 should be "deployed" and changed as such. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1769354962 From jlu at openjdk.org Fri Sep 20 23:41:11 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 20 Sep 2024 23:41:11 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v5] In-Reply-To: References: <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com> Message-ID: On Fri, 20 Sep 2024 12:58:59 GMT, Alan Bateman wrote: >> Thanks for taking a look Alan. Your test comments should be addressed in https://github.com/openjdk/jdk/pull/21076/commits/790abd039dd08ca1e0575feca29f681a2507d902. >> Did you have any comments on the current doc change? > >> Did you have any comments on the current doc change? > > I've been slow to reply on that because I'm not 100% sure if the spec is correct. Can you double check that the CCL is actually used. I think it uses the system class loader, and maybe the platform class loader for the extended charsets. Hi Alan, I think you're right that the CCL is not used. The standard charsets are loaded via the SystemClassLoader, the extended are loaded via the platformClassLoader, and BazProvider does appear to be loaded via the SystemClassLoader. See below, // Assert default context class loader is the system class loader Thread.currentThread().getContextClassLoader(); // default context class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93 ClassLoader.getSystemClassLoader(); // system class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93 // Change the default context class loader Thread.currentThread().setContextClassLoader(new FooLoader()); // Change default context class loader to not be the system // Check the class loaders for the various Charsets Charset.availableCharsets().get("utf-8").getClassLoader(); // standard -> null Charset.availableCharsets().get("Big5").getClassLoader(); // extended -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 55a95ab1 Charset.availableCharsets().get("BAZ").getClassLoader(); // provider -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93 Thread.currentThread().getContextClassLoader(); // context class loader -> CharsetProviderAsModuleTest$FooLoader at 1d15c6cc Can we simply omit the line: "_Charset providers are looked up via the current thread's context class loader_". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1769354840 From alanb at openjdk.org Sat Sep 21 05:58:38 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 21 Sep 2024 05:58:38 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v5] In-Reply-To: References: <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com> Message-ID: <-U9GTEry_sU8-ivH74GzV59gTCqwJLM2rbt7rZqFYZg=.389fc9a2-eba1-4250-bbb7-5501831c23d2@github.com> On Fri, 20 Sep 2024 23:37:18 GMT, Justin Lu wrote: >>> Did you have any comments on the current doc change? >> >> I've been slow to reply on that because I'm not 100% sure if the spec is correct. Can you double check that the CCL is actually used. I think it uses the system class loader, and maybe the platform class loader for the extended charsets. > > Hi Alan, > > I think you're right that the CCL is not used. > > The standard charsets are loaded via the SystemClassLoader, the extended are loaded via the platformClassLoader, and BazProvider does appear to be loaded via the SystemClassLoader. See below, > > > // Assert default context class loader is the system class loader > Thread.currentThread().getContextClassLoader(); // default context class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93 > ClassLoader.getSystemClassLoader(); // system class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93 > > // Change the default context class loader > Thread.currentThread().setContextClassLoader(new FooLoader()); // Change default context class loader to not be the system > > // Check the class loaders for the various Charsets > Charset.availableCharsets().get("utf-8").getClassLoader(); // standard -> null > Charset.availableCharsets().get("Big5").getClassLoader(); // extended -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 55a95ab1 > Charset.availableCharsets().get("BAZ").getClassLoader(); // provider -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93 > Thread.currentThread().getContextClassLoader(); // context class loader -> CharsetProviderAsModuleTest$FooLoader at 1d15c6cc > > > Can we simply omit the line: > > "_Charset providers are looked up via the current thread's context class loader_". Thanks for checking. I remember [JDK-4619777 ](https://bugs.openjdk.org/browse/JDK-4619777) and it's possible there are one or two other JBS issue on the topic. It may be been interesting to include a charset provider with a dynamically loaded application at one point but seems less interesting in 2024. So I think we should just update the spec to align with the long standing behavior, meaning specify that the charset provider must be visible to the system class loader. I think "by some other platform-specific means" by can be dropped too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1769483298 From duke at openjdk.org Sat Sep 21 15:49:36 2024 From: duke at openjdk.org (Markus KARG) Date: Sat, 21 Sep 2024 15:49:36 GMT Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux) In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 11:08:11 GMT, Alan Bateman wrote: > I think the Socket and Pipe changes need to be separated and the merits of each discussed separately. I understand your intention, and that should be possible on Linux, but on Windows this is impossible as the Pipe implementation on Windows actually is just a wrapper around the Socker implementation. As all OS share common code, in fact I do not see the possibility to separate Sockets and Pipes hence. Possible I missed an obvious solution to that interrelation, then please tell me. > Starting with the changes to improve InputStream.skip when connected to a socket seems okay. There are two implementations, one is the SocketImpl implementation used by the Socket API (not changed here), the other is implementation returned by SocketChannel::socket which is changed here. It seems plausible that improving skip will help some use-cases. My initial reaction to touching this area is that will likely require clarifications to the specification of Socket.getInputStream, e.g. this method doesn't specify how show skip behaves when a timeout is set, doesn't specify IllegalBlockingModeException when the channel is non-blocking, and doesn't specify how it behaves when the Thread is interrupted. Thank you for your kind review. I will look into adding some JavaDocs to better express the behavior of the changed classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2365232471 From jlu at openjdk.org Sat Sep 21 18:13:12 2024 From: jlu at openjdk.org (Justin Lu) Date: Sat, 21 Sep 2024 18:13:12 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v6] In-Reply-To: References: Message-ID: <1J824jNqjjAw-bd6wMBxP-gH5JfSrQT6b10B2BKS_Og=.26102276-59bd-40ea-9de7-5d77d614943a@github.com> > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. > > This came as a result from a comment on the PR of JDK-8339735. > > I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. > > An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: review: spec correction - system class loader used, not context ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21076/files - new: https://git.openjdk.org/jdk/pull/21076/files/c4056ba8..d90f6ca0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=04-05 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21076/head:pull/21076 PR: https://git.openjdk.org/jdk/pull/21076 From jlu at openjdk.org Sat Sep 21 18:15:34 2024 From: jlu at openjdk.org (Justin Lu) Date: Sat, 21 Sep 2024 18:15:34 GMT Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module path [v6] In-Reply-To: <-U9GTEry_sU8-ivH74GzV59gTCqwJLM2rbt7rZqFYZg=.389fc9a2-eba1-4250-bbb7-5501831c23d2@github.com> References: <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com> <-U9GTEry_sU8-ivH74GzV59gTCqwJLM2rbt7rZqFYZg=.389fc9a2-eba1-4250-bbb7-5501831c23d2@github.com> Message-ID: On Sat, 21 Sep 2024 05:55:46 GMT, Alan Bateman wrote: >> Hi Alan, >> >> I think you're right that the CCL is not used. >> >> The standard charsets are loaded via the SystemClassLoader, the extended are loaded via the platformClassLoader, and BazProvider does appear to be loaded via the SystemClassLoader. See below, >> >> >> // Assert default context class loader is the system class loader >> Thread.currentThread().getContextClassLoader(); // default context class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93 >> ClassLoader.getSystemClassLoader(); // system class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93 >> >> // Change the default context class loader >> Thread.currentThread().setContextClassLoader(new FooLoader()); // Change default context class loader to not be the system >> >> // Check the class loaders for the various Charsets >> Charset.availableCharsets().get("utf-8").getClassLoader(); // standard -> null >> Charset.availableCharsets().get("Big5").getClassLoader(); // extended -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 55a95ab1 >> Charset.availableCharsets().get("BAZ").getClassLoader(); // provider -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93 >> Thread.currentThread().getContextClassLoader(); // context class loader -> CharsetProviderAsModuleTest$FooLoader at 1d15c6cc >> >> >> Can we simply omit the line: >> >> "_Charset providers are looked up via the current thread's context class loader_". > > Thanks for checking. I remember [JDK-4619777 ](https://bugs.openjdk.org/browse/JDK-4619777) and it's possible there are one or two other JBS issue on the topic. It may be been interesting to include a charset provider with a dynamically loaded application at one point but seems less interesting in 2024. So I think we should just update the spec to align with the long standing behavior, meaning specify that the charset provider must be visible to the system class loader. I think "by some other platform-specific means" by can be dropped too. Updated in https://github.com/openjdk/jdk/pull/21076/commits/d90f6ca0dcc1f5fd6d74af58c4cb2b0d14d1666e. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1769632649 From alanb at openjdk.org Sun Sep 22 07:50:42 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 22 Sep 2024 07:50:42 GMT Subject: RFR: 8340404: CharsetProvider specification updates [v6] In-Reply-To: <1J824jNqjjAw-bd6wMBxP-gH5JfSrQT6b10B2BKS_Og=.26102276-59bd-40ea-9de7-5d77d614943a@github.com> References: <1J824jNqjjAw-bd6wMBxP-gH5JfSrQT6b10B2BKS_Og=.26102276-59bd-40ea-9de7-5d77d614943a@github.com> Message-ID: On Sat, 21 Sep 2024 18:13:12 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. >> >> This came as a result from a comment on the PR of JDK-8339735. >> >> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. >> >> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. >> >> Additionally some outdated info is corrected as part of this change. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > review: spec correction - system class loader used, not context src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 38: > 36: * zero-argument constructor and some number of associated {@code Charset} > 37: * implementation classes. Charset providers are deployed by adding them to either > 38: * the application module path or the application class path. In order to be looked The latest update to the class description looks quite good. I think this sentence can be simplified down to "Charset provider are deployed on the application module path ...". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1770051344 From pminborg at openjdk.org Mon Sep 23 11:00:48 2024 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 23 Sep 2024 11:00:48 GMT Subject: Integrated: 8325949: Create an internal utility method for creating VarHandle instances In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 17:38:44 GMT, Per Minborg wrote: > This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations. > > While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples: > > | Class File | Base [Bytes] | Patch [Byte] | > | --------------------------------| ------------- | ------------ | > | FutureTask.class | 10,255 | 10,123 | > | AtomicBoolean.class | 5,364 | 5,134 | > |AtomicMarkableReference.class | 3,890 | 3,660 | > > ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc) > > The new `MethodHandlesInternal.class` file is of size 1,952 bytes. > > In total for `java.base` we have: > > | Build map "jdk" | Size [Bytes] | > | ---------------| ------------- | > | Base | 5,906,457 | > | Patch | 5,905,487 | > | Delta | 940| > > For 60 billion instances, this represents > 50 TB. > > Tried and passed tier1-3 This pull request has now been integrated. Changeset: 384deda6 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/384deda65fd63e23d4caaaa9762f2ac80de78029 Stats: 442 lines in 31 files changed: 125 ins; 210 del; 107 mod 8325949: Create an internal utility method for creating VarHandle instances Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/20972 From jlu at openjdk.org Mon Sep 23 17:20:52 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 23 Sep 2024 17:20:52 GMT Subject: RFR: 8340404: CharsetProvider specification updates [v7] In-Reply-To: References: Message-ID: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. > > This came as a result from a comment on the PR of JDK-8339735. > > I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. > > An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. > > Additionally some outdated info is corrected as part of this change. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: review: simplify wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21076/files - new: https://git.openjdk.org/jdk/pull/21076/files/d90f6ca0..08e8161c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21076/head:pull/21076 PR: https://git.openjdk.org/jdk/pull/21076 From jlu at openjdk.org Mon Sep 23 17:20:52 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 23 Sep 2024 17:20:52 GMT Subject: RFR: 8340404: CharsetProvider specification updates [v6] In-Reply-To: References: <1J824jNqjjAw-bd6wMBxP-gH5JfSrQT6b10B2BKS_Og=.26102276-59bd-40ea-9de7-5d77d614943a@github.com> Message-ID: On Sun, 22 Sep 2024 07:48:03 GMT, Alan Bateman wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> review: spec correction - system class loader used, not context > > src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 38: > >> 36: * zero-argument constructor and some number of associated {@code Charset} >> 37: * implementation classes. Charset providers are deployed by adding them to either >> 38: * the application module path or the application class path. In order to be looked > > The latest update to the class description looks quite good. I think this sentence can be simplified down to "Charset provider are deployed on the application module path ...". Fixed in https://github.com/openjdk/jdk/pull/21076/commits/08e8161c3d9a6c2efca7b5f578a72060537495e9 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1771819878 From alanb at openjdk.org Mon Sep 23 17:24:39 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 23 Sep 2024 17:24:39 GMT Subject: RFR: 8340404: CharsetProvider specification updates [v7] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 17:20:52 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. >> >> This came as a result from a comment on the PR of JDK-8339735. >> >> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. >> >> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. >> >> Additionally some outdated info is corrected as part of this change. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > review: simplify wording Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21076#pullrequestreview-2322889142 From jlu at openjdk.org Mon Sep 23 18:42:38 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 23 Sep 2024 18:42:38 GMT Subject: RFR: 8340404: CharsetProvider specification updates [v6] In-Reply-To: References: <1J824jNqjjAw-bd6wMBxP-gH5JfSrQT6b10B2BKS_Og=.26102276-59bd-40ea-9de7-5d77d614943a@github.com> Message-ID: On Sun, 22 Sep 2024 07:48:03 GMT, Alan Bateman wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> review: spec correction - system class loader used, not context > > src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 38: > >> 36: * zero-argument constructor and some number of associated {@code Charset} >> 37: * implementation classes. Charset providers are deployed by adding them to either >> 38: * the application module path or the application class path. In order to be looked > > The latest update to the class description looks quite good. I think this sentence can be simplified down to "Charset provider are deployed on the application module path ...". Thanks for the approval @AlanBateman . Could you also review the [CSR](https://bugs.openjdk.org/browse/JDK-8340412) when you get the chance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1771916116 From naoto at openjdk.org Mon Sep 23 23:04:35 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 23 Sep 2024 23:04:35 GMT Subject: RFR: 8340404: CharsetProvider specification updates [v7] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 17:20:52 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. >> >> This came as a result from a comment on the PR of JDK-8339735. >> >> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. >> >> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. >> >> Additionally some outdated info is corrected as part of this change. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > review: simplify wording Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21076#pullrequestreview-2323665232 From alanb at openjdk.org Fri Sep 27 07:39:36 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 27 Sep 2024 07:39:36 GMT Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux) In-Reply-To: References: Message-ID: On Sat, 21 Sep 2024 15:47:05 GMT, Markus KARG wrote: > I will look into adding some JavaDocs to better express the behavior of the changed classes. In addition to skip, the other methods that may be implemented with more than one read are the transferTo, readAllBytes, readNBytes, ... all methods added since JDK 1.0. It may be that Socket's class level description or the setSoTimeout method will need wording to say that it is implementation specific as to how the configured timeouts works with these methods. It may apply to the entire operation or ports of, tricky to word. The issue of skip or any of the other methods throwing IllegalBlockingModeException can probably be confined to the Socket.getInputStream's API docs where it already documents this exception as possible when reading. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2378612632 From jlu at openjdk.org Fri Sep 27 18:28:42 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 27 Sep 2024 18:28:42 GMT Subject: RFR: 8340404: CharsetProvider specification updates [v7] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 17:20:52 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. >> >> This came as a result from a comment on the PR of JDK-8339735. >> >> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. >> >> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. >> >> Additionally some outdated info is corrected as part of this change. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > review: simplify wording Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21076#issuecomment-2379831212 From jlu at openjdk.org Fri Sep 27 18:28:43 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 27 Sep 2024 18:28:43 GMT Subject: Integrated: 8340404: CharsetProvider specification updates In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 00:07:30 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path. > > This came as a result from a comment on the PR of JDK-8339735. > > I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself. > > An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module. > > Additionally some outdated info is corrected as part of this change. This pull request has now been integrated. Changeset: 082125d6 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/082125d61e4b7e0fd53528c0271ca8be621f242b Stats: 157 lines in 4 files changed: 143 ins; 1 del; 13 mod 8340404: CharsetProvider specification updates Reviewed-by: alanb, naoto ------------- PR: https://git.openjdk.org/jdk/pull/21076 From eirbjo at openjdk.org Mon Sep 30 19:14:45 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 30 Sep 2024 19:14:45 GMT Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array size in java.base Message-ID: Please review this cleanup PR which updates code and tests in `java.base` to consistently use `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation. This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`. My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site). I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found. Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR. Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`. Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green. ------------- Commit messages: - Add @modules jtreg tag to XcodeOverflow test, required to use ArraysSupport.SOFT_MAX_ARRAY_LENGTH - Consolidate and use ArraysSupport.SOFT_MAX_ARRAY_LENGTH in place of Integer.MAX_VALUE - 8 Changes: https://git.openjdk.org/jdk/pull/21268/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21268&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341243 Stats: 64 lines in 15 files changed: 23 ins; 9 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/21268.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21268/head:pull/21268 PR: https://git.openjdk.org/jdk/pull/21268 From bpb at openjdk.org Mon Sep 30 23:02:05 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 30 Sep 2024 23:02:05 GMT Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer (Linux) Message-ID: Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer. ------------- Commit messages: - 8341282: (fs) Move creation time fallback logic to Java layer (Linux) Changes: https://git.openjdk.org/jdk/pull/21274/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21274&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341282 Stats: 20 lines in 2 files changed: 5 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/21274.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21274/head:pull/21274 PR: https://git.openjdk.org/jdk/pull/21274 From bpb at openjdk.org Mon Sep 30 23:24:37 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 30 Sep 2024 23:24:37 GMT Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back to epoch if birth time is unavailable (Linux) [v2] In-Reply-To: References: <8uO3dA3UYD5UDVb9FrNf-JSACS86o-5dZKMcZ7KD-hA=.d67b5ab1-c7df-40ed-9da4-01efc359e651@github.com> <5oOvufswuiCF1In92xBLABrpWdrZVuP0d_dRD-rjVl0=.b21ac190-5f2f-447f-bc71-ddc599288004@github.com> <2GcDA0gVCJbmu1qieXHdev877w-UopfpKOZ8MlpfzUs=.eb5cea48-6192-40a7-a3be-9827eb159069@github.com> Message-ID: On Wed, 21 Aug 2024 16:29:59 GMT, Severin Gehwolf wrote: >> It should have as there was a behavioral change: creation time changed from last modified time to epoch when the birth time is not available. > > Fair enough. > I guess is okay although I think I'd much prefer to decide this in the Java code. Maybe we can re-examine this again in the future. This is addressed by [JDK-8341282](https://bugs.openjdk.org/browse/JDK-8341282). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20655#discussion_r1781905311