From duke at openjdk.org Thu Jun 1 17:07:06 2023 From: duke at openjdk.org (Terry Chow) Date: Thu, 1 Jun 2023 17:07:06 GMT Subject: RFR: 8308593: Add Keepalive Extended Socket Options Support for Windows In-Reply-To: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com> References: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com> Message-ID: On Tue, 30 May 2023 22:46:05 GMT, Terry Chow wrote: > The PR adds support for setting the keepalive extended socket options on Windows. The implemented native code uses the SIO_KEEPALIVE_VALS control code, which is how keepalive values are set on Windows and so there are a few caveats. > > 1. The keepalive time and keepalive interval must both be set at the same time. In the implementation, a new SioKeepAlive class and ExtendedSocketOptions is created to capture this behaviour for Windows only. Keepalive enablement must also be configured when using SIO_KEEPALIVE_VALS, and so by default when setting keepalive time and keepalive interval, > keepalive will automatically be enabled. > > [SIO_KEEPALIVE_VALS doc](https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals) > > 2. It doesn't seem possible to acquire the Keepalive time and keepalive interval values on Windows. So, the implementation doesn't support acquiring the values. > > https://stackoverflow.com/questions/14197347/how-to-query-socket-keep-alive-values-using-winsock/14198462#14198462 > https://stackoverflow.com/questions/18391341/reading-sio-keepalive-vals-fields-on-a-windows-socket-for-keepalive-idle-and-in > > 3. Keepalive probes are not supported. On Windows Vista and later, the number of keep-alive probes is set to 10 and cannot be changed. > > [SIO_KEEPALIVE_VALS Remarks](https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals#remarks) > > For testing, I've updated the existing keepalive tests. But, since it's not possible to acquire the keepalive values on Windows to verify, I've indirectly tested setting the keepalive values by confirming keepalive is enabled where possible (since keepalive is enabled also when keepalive values are set). Apologies, I was talking to my liaison on what's the appropriate way to communicate (as I don't have a JBS account). Let me know if it's alright to discuss things here. Thanks for the quick reply on your thoughts. >The proposal that you have here is a new Windows specific and JDK-specific socket option that requires a lot of thinking about before going that route. I had similar thoughts as well, that this implementation was more of a "last resort". I've had other ideas of ways to go about this that I'll mention below, but there were some contentions and so this implementation was the most straightforward to do to get something working in order to have open dialog. But yeah, absolutely agree on more discussion. >It would be useful to know if the semantics of the SIO_KEEPALIVE_VALS control code is the equivalent of the TCP_KEEPIDLE + TCP_KEEPINTERVAL on other platforms. Yes, that's correct. SIO_KEEPALIVE_VALS is the Windows equivalent of setting the keep alive values on a per socket basis (only difference is that both are set at the same time). > It would also be useful to know if Windows has a system-wide default value for both the keep alive idle and interval. If it does then it might be possible to use the existing extended options, which if under the covers that both need to be set at the same time. So, the system-wide default keep alive idle and interval for Windows is 2hrs and 1s respectively. I also thought of using default values, but the issue is this: defaultKeepAliveTime = 2hrs defaultKeepAliveInterval = 1s 1. setKeepAliveTime(1hr) // user sets the keepAliveTime 2. setKeepAlive(1hr, defaultKeepAliveInterval) // under the covers we set both values 3. setKeepAliveInterval(20s) // user later sets the interval time 4. setKeepAlive(defaultKeepAliveTime, 20s) // prior keepAliveTime of 1hr is now back to default But we can get around this by keeping track of the current set keepAlive values. defaultKeepAliveTime = 2hrs defaultKeepAliveInterval = 1s currentKeepAliveTime = defaultKeepAliveTime currentKeepAliveInterval = defaultKeepAliveInterval 1. setKeepAliveTime(1hr) // user sets the keepAliveTime 2. setKeepAlive(1hr, currentKeepAliveInterval) // under the covers we set both values, keep track of new keepAliveTime value currentKeepAliveTime = 1hr 3. setKeepAliveInterval(20s) // user later sets the interval time 4. setKeepAlive(currentKeepAliveTime, 20s) // use prior set keepAliveTime currentKeepAliveInterval = 20s However, we can't keep track of the current keep alive values in `WindowsSocketOptions` as the same instance is shared by all socket instances. The place that makes the most sense to keep track of the current keep alive values seems like at the socket class level. What are your thoughts on keeping track of the values at the socket level? I was hesistant on this route because it doesn't seem right to track Windows only keep alive values at the socket class level. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14232#issuecomment-1572442618 From bpb at openjdk.org Thu Jun 1 20:16:15 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 1 Jun 2023 20:16:15 GMT Subject: RFR: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists Message-ID: If the second attempt to create the link fails, throw the exception referring to the last error if it is anything other than due to lack of link creation privilege or failure to recognize the flag for unprivileged link creation. ------------- Commit messages: - 8307887: Excise trailing whitespace - 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists Changes: https://git.openjdk.org/jdk/pull/14255/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14255&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307887 Stats: 26 lines in 2 files changed: 20 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14255/head:pull/14255 PR: https://git.openjdk.org/jdk/pull/14255 From alanb at openjdk.org Fri Jun 2 05:49:08 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 2 Jun 2023 05:49:08 GMT Subject: RFR: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 01:39:16 GMT, Brian Burkhalter wrote: > If the second attempt to create the link fails, throw the exception referring to the last error if it is anything other than due to lack of link creation privilege or failure to recognize the flag for unprivileged link creation. src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 994: > 992: int lastError = y.lastError(); > 993: if (lastError != ERROR_PRIVILEGE_NOT_HELD && lastError != ERROR_INVALID_PARAMETER) > 994: throw y; The methods that WindowsNativeDispatcher defines are meant to be 1-1 mapping to win32 calls. It looks like we put the changes for JDK-8221852 in the wrong place, they need to be the usage rather than here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14255#discussion_r1213948493 From duke at openjdk.org Fri Jun 2 10:14:00 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 2 Jun 2023 10:14:00 GMT Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base Message-ID: Compiling on AIX with xlc17 which contains the new clang 15 frontend shows the following warnings. built by make/modules/java.base/Lib.gmk src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error); ^ src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] end = (void *)nddp + size; ~~~~~~~~~~~~ ^ src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef] #elif _ALLBSD_SOURCE built by make/modules/java.base/lib/CoreLibraries.gmk src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' if (ret < sizeof(psinfo_t)) { ^ src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] addr < p->ldinfo_textorg + p->ldinfo_textsize) { ~~~~~~~~~~~~~~~~~ ^ src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] void ZLIB_INTERNAL inflate_fast(strm, start) ^ src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vfprintf(stderr, fmt, vl); ^~~ The test library libGetXSpace.c also shows a warning. In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that. ------------- Commit messages: - JDK-8309219 Changes: https://git.openjdk.org/jdk/pull/14281/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14281&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309219 Stats: 12 lines in 6 files changed: 3 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/14281.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14281/head:pull/14281 PR: https://git.openjdk.org/jdk/pull/14281 From bpb at openjdk.org Fri Jun 2 16:32:38 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 2 Jun 2023 16:32:38 GMT Subject: RFR: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists [v2] In-Reply-To: References: Message-ID: > If the second attempt to create the link fails, throw the exception referring to the last error if it is anything other than due to lack of link creation privilege or failure to recognize the flag for unprivileged link creation. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8307887: Move unprivileged link creation logic to WindowsLinkSupport ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14255/files - new: https://git.openjdk.org/jdk/pull/14255/files/4dba50d0..255f5c7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14255&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14255&range=00-01 Stats: 60 lines in 4 files changed: 30 ins; 20 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/14255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14255/head:pull/14255 PR: https://git.openjdk.org/jdk/pull/14255 From bpb at openjdk.org Fri Jun 2 16:32:39 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 2 Jun 2023 16:32:39 GMT Subject: RFR: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 05:46:20 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8307887: Move unprivileged link creation logic to WindowsLinkSupport > > src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 994: > >> 992: int lastError = y.lastError(); >> 993: if (lastError != ERROR_PRIVILEGE_NOT_HELD && lastError != ERROR_INVALID_PARAMETER) >> 994: throw y; > > The methods that WindowsNativeDispatcher defines are meant to be 1-1 mapping to win32 calls. It looks like we put the changes for JDK-8221852 in the wrong place, they need to be the usage rather than here. Restored `WindowsNativeDispatcher` 1:1 mapping for `CreateSymbolcLink`: logic moved to a new static method in `WindowsLinkSupport` (255f5c7f8d86a3d653fb648ed993bb4589792881). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14255#discussion_r1214582203 From alanb at openjdk.org Sun Jun 4 13:45:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 4 Jun 2023 13:45:06 GMT Subject: RFR: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 16:32:38 GMT, Brian Burkhalter wrote: >> If the second attempt to create the link fails, throw the exception referring to the last error if it is anything other than due to lack of link creation privilege or failure to recognize the flag for unprivileged link creation. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8307887: Move unprivileged link creation logic to WindowsLinkSupport test/jdk/java/nio/file/Files/Links.java line 63: > 61: Files.deleteIfExists(pathTarget); > 62: } > 63: I think it's confusing to have a test for sym links before testing if sym links are supported. I think it's okay to not include tests that target very specific cases like Windows "developer mode" but a test that the optional specific exception is thrown is okay, it just feels like it should be just one of the tests, rather than done before knowing the test can run, e.g. try this on a non-NTFS system and I assume createSymbolicLink will fail and cause the test to fail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14255#discussion_r1216712935 From bpb at openjdk.org Mon Jun 5 15:47:10 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 5 Jun 2023 15:47:10 GMT Subject: RFR: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists [v2] In-Reply-To: References: Message-ID: On Sun, 4 Jun 2023 13:42:02 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8307887: Move unprivileged link creation logic to WindowsLinkSupport > > test/jdk/java/nio/file/Files/Links.java line 63: > >> 61: Files.deleteIfExists(pathTarget); >> 62: } >> 63: > > I think it's confusing to have a test for sym links before testing if sym links are supported. I think it's okay to not include tests that target very specific cases like Windows "developer mode" but a test that the optional specific exception is thrown is okay, it just feels like it should be just one of the tests, rather than done before knowing the test can run, e.g. try this on a non-NTFS system and I assume createSymbolicLink will fail and cause the test to fail. Logically I don't like the ordering either but without this happening first the error was not reproduced on the pre-PR code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14255#discussion_r1218264643 From bpb at openjdk.org Mon Jun 5 18:19:50 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 5 Jun 2023 18:19:50 GMT Subject: RFR: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 15:43:47 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/file/Files/Links.java line 63: >> >>> 61: Files.deleteIfExists(pathTarget); >>> 62: } >>> 63: >> >> I think it's confusing to have a test for sym links before testing if sym links are supported. I think it's okay to not include tests that target very specific cases like Windows "developer mode" but a test that the optional specific exception is thrown is okay, it just feels like it should be just one of the tests, rather than done before knowing the test can run, e.g. try this on a non-NTFS system and I assume createSymbolicLink will fail and cause the test to fail. > > Logically I don't like the ordering either but without this happening first the error was not reproduced on the pre-PR code. Perhaps it would be better to revert the test change altogether and label the issue `noreg-hard`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14255#discussion_r1218429494 From alanb at openjdk.org Mon Jun 5 19:37:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 5 Jun 2023 19:37:54 GMT Subject: RFR: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 18:16:27 GMT, Brian Burkhalter wrote: > Perhaps it would be better to revert the test change altogether and label the issue `noreg-hard`? I was thinking the same. Main concern with the test change is that it will likely fail in some environments so we'll end up trying to come up a way to test what is inherently difficult scenario to test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14255#discussion_r1218507381 From bpb at openjdk.org Mon Jun 5 21:11:56 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 5 Jun 2023 21:11:56 GMT Subject: RFR: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists [v3] In-Reply-To: References: Message-ID: <7ZD5_XGzCrSPtaq3iayMLo9psHgqeNan6staw5yUJqo=.2013c470-6579-4628-8ac8-c6dafa9f1b7f@github.com> > If the second attempt to create the link fails, throw the exception referring to the last error if it is anything other than due to lack of link creation privilege or failure to recognize the flag for unprivileged link creation. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8307887: Revert test change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14255/files - new: https://git.openjdk.org/jdk/pull/14255/files/255f5c7f..dacc8f57 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14255&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14255&range=01-02 Stats: 15 lines in 1 file changed: 0 ins; 13 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14255/head:pull/14255 PR: https://git.openjdk.org/jdk/pull/14255 From duke at openjdk.org Mon Jun 5 21:29:03 2023 From: duke at openjdk.org (duke) Date: Mon, 5 Jun 2023 21:29:03 GMT Subject: Withdrawn: 8303934: (fc) Use splice in FileChannel::transferFrom when the source is a pipe (Linux) In-Reply-To: References: Message-ID: <9-GKL_M-hO-9uFIBPW91g6XVgev0qF4uSW64nRdh5J8=.589ea056-b8cd-4b96-abc4-c15c2fba8991@github.com> On Fri, 10 Mar 2023 00:35:38 GMT, Brian Burkhalter wrote: > On Linux, perform `transferFrom()` via the `splice(2)` system call when the source `ReadableByteChannel` is a `Pipe.SourceChannel` (`sun.nio.ch.SourceChannelImpl`). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12965 From duke at openjdk.org Tue Jun 6 06:06:51 2023 From: duke at openjdk.org (Deepa Kumari) Date: Tue, 6 Jun 2023 06:06:51 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> Message-ID: On Thu, 25 May 2023 07:37:27 GMT, Alan Bateman wrote: >> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. >> >> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group. >> >> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. >> >> >> >> >> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807) > > I've moved the JBS issue to the right place and fix the description. > > The changes proposed here impact all platforms and will require discussion and cleanup. If I understand the intent, if you create a DatagramSocket or MulticastSocket that is bound to a specific local address then you want to use that to determine if the underlying socket is IPv4 or IPv6. That might be okay but multicasting normally means binding to the wildcard address so it doesn't help - I assume it only works for the test because new InetSocketAddress(port).getAddress() returns an Inet4Address so you get an IPv4 socket. It should only create a dual IPv4/IPv6 socket for this case so this is why it will break other platforms. In any case, can you look at the isXXX methods defined by sun.nio.ch.Net to see how it is handled on other platforms. Yes, I agree with @AlanBateman and @msheppar . Even when we try to have an IPv4 multicast socket join an IPv4 multicast group, we still fail because the delegate that is created for an IPv4 multicast socket is IPv4/IPv6 (dual stack) in nature. AIX does not allow dual stack (IPv4/IPv6) sockets to join IPv4 multicast groups. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1577968863 From alanb at openjdk.org Tue Jun 6 06:18:53 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jun 2023 06:18:53 GMT Subject: RFR: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists [v3] In-Reply-To: <7ZD5_XGzCrSPtaq3iayMLo9psHgqeNan6staw5yUJqo=.2013c470-6579-4628-8ac8-c6dafa9f1b7f@github.com> References: <7ZD5_XGzCrSPtaq3iayMLo9psHgqeNan6staw5yUJqo=.2013c470-6579-4628-8ac8-c6dafa9f1b7f@github.com> Message-ID: On Mon, 5 Jun 2023 21:11:56 GMT, Brian Burkhalter wrote: >> If the second attempt to create the link fails, throw the exception referring to the last error if it is anything other than due to lack of link creation privilege or failure to recognize the flag for unprivileged link creation. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8307887: Revert test change Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14255#pullrequestreview-1464343644 From alanb at openjdk.org Tue Jun 6 07:28:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jun 2023 07:28:55 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> Message-ID: On Thu, 25 May 2023 07:37:27 GMT, Alan Bateman wrote: >> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. >> >> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group. >> >> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. >> >> >> >> >> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807) > > I've moved the JBS issue to the right place and fix the description. > > The changes proposed here impact all platforms and will require discussion and cleanup. If I understand the intent, if you create a DatagramSocket or MulticastSocket that is bound to a specific local address then you want to use that to determine if the underlying socket is IPv4 or IPv6. That might be okay but multicasting normally means binding to the wildcard address so it doesn't help - I assume it only works for the test because new InetSocketAddress(port).getAddress() returns an Inet4Address so you get an IPv4 socket. It should only create a dual IPv4/IPv6 socket for this case so this is why it will break other platforms. In any case, can you look at the isXXX methods defined by sun.nio.ch.Net to see how it is handled on other platforms. > Yes, I agree with @AlanBateman and @msheppar . Even when we try to have an IPv4 multicast socket join an IPv4 multicast group, we still fail because the delegate that is created for an IPv4 multicast socket is IPv4/IPv6 (dual stack) in nature. AIX does not allow dual stack (IPv4/IPv6) sockets to join IPv4 multicast groups. The "Platform dependencies" in java.nio.channels.MulticastChannel (implemented by DatagramChannel) makes it clear that it is implementation specific as to whether a channel to an IPv6 socket can join an IPv4 multicast group. The recommendation is to specify the protocol family when creating the channel. Legacy DatagramSocket/MulticastSocket do not define a constructor that allows the protocol family be specified at xxxSocket create time. That issue has been there since JDK 1.4 when IPv6 support was added. I'm curious why this might be coming up with AIX now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1578072460 From goetz at openjdk.org Tue Jun 6 08:23:51 2023 From: goetz at openjdk.org (Goetz Lindenmaier) Date: Tue, 6 Jun 2023 08:23:51 GMT Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base In-Reply-To: References: Message-ID: <-yWpqiFZdPQLUCdoh0AObCt0RLIgVZpXIBdQFTAKidQ=.f35114ab-6248-4c50-9f50-d9015dbc204b@github.com> On Fri, 2 Jun 2023 10:08:09 GMT, JoKern65 wrote: > This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146 > It handles the part in java.base. > > Compiling on AIX with xlc17 which contains the new clang 15 frontend > shows the following warnings. > > built by make/modules/java.base/Lib.gmk > > src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] > proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error); > ^ > > > src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] > end = (void *)nddp + size; > > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef] > #elif _ALLBSD_SOURCE > The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten. > > built by make/modules/java.base/lib/CoreLibraries.gmk > > src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' > if (ret < sizeof(psinfo_t)) { > ProcessHandleImpl_unix.c: Just using the proper type `size_t` instead of `int`. > > > src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] > addr < p->ldinfo_textorg + p->ldinfo_textsize) { > we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk > > src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] > void ZLIB_INTERNAL inflate_fast(strm, start) > ^ > src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] > vfprintf(stderr, fmt, vl); > ^~~ > > The test library libGetXSpace.c also shows a warning. > In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that. Lib.gmk / DefaultProxySelector.c Fixing this in the file would require a larger rework. Good. Lib.gmk / NetworkInterface.c This looks as if it could also be fixed in the code. But previously, other warnings have not been fixed either. So I'm fine with this. CoreLibraries / deprecated-non-prototype Fixes warning in zlib, we should not touch the code there as it is from external. Good. CoreLibraries / format-nonliteral In hotspot, these warnings have been fixed, or an attribute is used to disable them locally. These places pop up in code scanners, too. See compilerWarnings.hpp / ATTRIBUTE_PRINTF(). The code here can not be fixed, and I don't see any usage of the attribute or similar in java.base, so disabling the warning seems fine to me. Also, it's treated similar in the other compile block. java_md_aix.c: good. ProcessHandleImpl_unix.c: good UnixNativeDispatcher.c: definitely an improvement to the code! libGetXSpace.c: good. A test library ------------- Marked as reviewed by goetz (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14281#pullrequestreview-1464571177 From bpb at openjdk.org Tue Jun 6 15:15:00 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Jun 2023 15:15:00 GMT Subject: RFR: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 19:35:16 GMT, Alan Bateman wrote: >> Perhaps it would be better to revert the test change altogether and label the issue `noreg-hard`? > >> Perhaps it would be better to revert the test change altogether and label the issue `noreg-hard`? > > I was thinking the same. Main concern with the test change is that it will likely fail in some environments so we'll end up trying to come up a way to test what is inherently difficult scenario to test. Test changes reverted in dacc8f5737f0ee716ac755b8b979cf2b22de4256; issue labelled `noreg-hard`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14255#discussion_r1219832768 From bpb at openjdk.org Tue Jun 6 15:18:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Jun 2023 15:18:08 GMT Subject: Integrated: 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 01:39:16 GMT, Brian Burkhalter wrote: > If the second attempt to create the link fails, throw the exception referring to the last error if it is anything other than due to lack of link creation privilege or failure to recognize the flag for unprivileged link creation. This pull request has now been integrated. Changeset: d709c25c Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/d709c25cbfdb0be007d3f800f7eddccce965809a Stats: 54 lines in 4 files changed: 30 ins; 13 del; 11 mod 8307887: (fs) Files.createSymbolicLink throws less specific exception when in developer mode and file already exists Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/14255 From duke at openjdk.org Wed Jun 7 09:03:27 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 7 Jun 2023 09:03:27 GMT Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base [v2] In-Reply-To: References: Message-ID: > This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146 > It handles the part in java.base. > > Compiling on AIX with xlc17 which contains the new clang 15 frontend > shows the following warnings. > > built by make/modules/java.base/Lib.gmk > > src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] > proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error); > ^ > > > src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] > end = (void *)nddp + size; > > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef] > #elif _ALLBSD_SOURCE > The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten. > > built by make/modules/java.base/lib/CoreLibraries.gmk > > src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' > if (ret < sizeof(psinfo_t)) { > ProcessHandleImpl_unix.c: Just using the proper type `size_t` instead of `int`. > > > src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] > addr < p->ldinfo_textorg + p->ldinfo_textsize) { > we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk > > src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] > void ZLIB_INTERNAL inflate_fast(strm, start) > ^ > src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] > vfprintf(stderr, fmt, vl); > ^~~ > > The test library libGetXSpace.c also shows a warning. > In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that. JoKern65 has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into JDK-8309219 - JDK-8309219 ------------- Changes: https://git.openjdk.org/jdk/pull/14281/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14281&range=01 Stats: 12 lines in 6 files changed: 3 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/14281.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14281/head:pull/14281 PR: https://git.openjdk.org/jdk/pull/14281 From mdoerr at openjdk.org Wed Jun 7 09:42:56 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 7 Jun 2023 09:42:56 GMT Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jun 2023 09:03:27 GMT, JoKern65 wrote: >> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146 >> It handles the part in java.base. >> >> Compiling on AIX with xlc17 which contains the new clang 15 frontend >> shows the following warnings. >> >> built by make/modules/java.base/Lib.gmk >> >> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] >> proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error); >> ^ >> >> >> src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] >> end = (void *)nddp + size; >> >> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef] >> #elif _ALLBSD_SOURCE >> The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten. >> >> built by make/modules/java.base/lib/CoreLibraries.gmk >> >> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' >> if (ret < sizeof(psinfo_t)) { >> ProcessHandleImpl_unix.c: Just using the proper type `size_t` instead of `int`. >> >> >> src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] >> addr < p->ldinfo_textorg + p->ldinfo_textsize) { >> we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk >> >> src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] >> void ZLIB_INTERNAL inflate_fast(strm, start) >> ^ >> src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] >> vfprintf(stderr, fmt, vl); >> ^~~ >> >> The test library libGetXSpace.c also shows a warning. >> In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that. > > JoKern65 has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into JDK-8309219 > - JDK-8309219 LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14281#pullrequestreview-1467159943 From duke at openjdk.org Wed Jun 7 11:23:26 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 7 Jun 2023 11:23:26 GMT Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base [v3] In-Reply-To: References: Message-ID: > This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146 > It handles the part in java.base. > > Compiling on AIX with xlc17 which contains the new clang 15 frontend > shows the following warnings. > > built by make/modules/java.base/Lib.gmk > > src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] > proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error); > ^ > > > src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] > end = (void *)nddp + size; > > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef] > #elif _ALLBSD_SOURCE > The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten. > > built by make/modules/java.base/lib/CoreLibraries.gmk > > src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' > if (ret < sizeof(psinfo_t)) { > ProcessHandleImpl_unix.c: Just using the proper type `size_t` instead of `int`. > > > src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] > addr < p->ldinfo_textorg + p->ldinfo_textsize) { > we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk > > src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] > void ZLIB_INTERNAL inflate_fast(strm, start) > ^ > src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] > vfprintf(stderr, fmt, vl); > ^~~ > > The test library libGetXSpace.c also shows a warning. > In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that. JoKern65 has updated the pull request incrementally with one additional commit since the last revision: Update libGetXSpace.c cast not necessary ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14281/files - new: https://git.openjdk.org/jdk/pull/14281/files/f185fa5d..7e8f5376 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14281&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14281&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14281.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14281/head:pull/14281 PR: https://git.openjdk.org/jdk/pull/14281 From mdoerr at openjdk.org Wed Jun 7 12:52:57 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 7 Jun 2023 12:52:57 GMT Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jun 2023 11:23:26 GMT, JoKern65 wrote: >> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146 >> It handles the part in java.base. >> >> Compiling on AIX with xlc17 which contains the new clang 15 frontend >> shows the following warnings. >> >> built by make/modules/java.base/Lib.gmk >> >> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] >> proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error); >> ^ >> >> >> src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] >> end = (void *)nddp + size; >> >> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef] >> #elif _ALLBSD_SOURCE >> The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten. >> >> built by make/modules/java.base/lib/CoreLibraries.gmk >> >> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' >> if (ret < sizeof(psinfo_t)) { >> ProcessHandleImpl_unix.c: Just using the proper type `size_t` instead of `int`. >> >> >> src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] >> addr < p->ldinfo_textorg + p->ldinfo_textsize) { >> we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk >> >> src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] >> void ZLIB_INTERNAL inflate_fast(strm, start) >> ^ >> src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] >> vfprintf(stderr, fmt, vl); >> ^~~ >> >> The test library libGetXSpace.c also shows a warning. >> In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > Update libGetXSpace.c > > cast not necessary Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14281#pullrequestreview-1467571356 From duke at openjdk.org Wed Jun 7 13:45:02 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 7 Jun 2023 13:45:02 GMT Subject: Integrated: JDK-8309219: Fix xlc17 clang 15 warnings in java.base In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 10:08:09 GMT, JoKern65 wrote: > This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146 > It handles the part in java.base. > > Compiling on AIX with xlc17 which contains the new clang 15 frontend > shows the following warnings. > > built by make/modules/java.base/Lib.gmk > > src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] > proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error); > ^ > > > src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] > end = (void *)nddp + size; > > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef] > #elif _ALLBSD_SOURCE > The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten. > > built by make/modules/java.base/lib/CoreLibraries.gmk > > src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' > if (ret < sizeof(psinfo_t)) { > ProcessHandleImpl_unix.c: Just using the proper type `size_t` instead of `int`. > > > src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] > addr < p->ldinfo_textorg + p->ldinfo_textsize) { > we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk > > src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] > void ZLIB_INTERNAL inflate_fast(strm, start) > ^ > src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] > vfprintf(stderr, fmt, vl); > ^~~ > > The test library libGetXSpace.c also shows a warning. > In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that. This pull request has now been integrated. Changeset: 6eddbe26 Author: JoKern65 <128386669+JoKern65 at users.noreply.github.com> Committer: Martin Doerr URL: https://git.openjdk.org/jdk/commit/6eddbe26dd0b9afb83fc029d77e18212e63f98f4 Stats: 12 lines in 6 files changed: 3 ins; 0 del; 9 mod 8309219: Fix xlc17 clang 15 warnings in java.base Reviewed-by: goetz, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/14281 From duke at openjdk.org Fri Jun 9 09:44:40 2023 From: duke at openjdk.org (Markus KARG) Date: Fri, 9 Jun 2023 09:44:40 GMT Subject: RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3] In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 19:07:15 GMT, Brian Burkhalter wrote: >...given that the intervals overlap by more than one third one must question the significance of the change. I see your statistical point (BTW overlap of just one third *is* good enough for me, as it is definitively *not the same* performance), but we are not just statisticians we are also engineers, and share the knowledge that *not executing* code *will* always be faster than *executing* code (I think the only difference we have is that you expect *more* improvement). So given the fact that still there is *some* improvement (the statistics do not imply that there is *no* improvement, it only implies that it is *small*), I really, really would like to contribute this change, still. My points are: * *Every single* spared CPU cycle is a good thing these days, even if the performance benefit is small for a *single* application, in the end this sums up to lots of spared CPU cycles when looking at the mere sum *all* applications on earth. In a mathematical sense: 1 * n still is n but not 0. * As a result, the world spares not only CPU cycles, but also spares power consumption, and with this, produces less need for cooling, which in turn spares power consumption. So in the end, in sum we globally spare some tons of CO2 per years. Even if it is only very few tons, it is a benefit for the world climate, gained for rather free. So why *not* doing it? * I see that we need to trade-off efforts, risk and benefit. For me, the effort from here to target is nearly zero, as the code is already done, is reviewed, is proven functional, and is test-covered. The additional risk of this PR is not much higher than the risk we accepted already with any other optimization we already did in the area of `transferTo` in the past years. For me, each single spared CPU cycle / each single spared ton of CO2 counts much, much more than anything else. So I plea to accept this PR, even if not statistically evident! :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13387#issuecomment-1584285102 From duke at openjdk.org Fri Jun 9 18:11:37 2023 From: duke at openjdk.org (Deepa Kumari) Date: Fri, 9 Jun 2023 18:11:37 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> Message-ID: On Tue, 6 Jun 2023 07:25:57 GMT, Alan Bateman wrote: >> I've moved the JBS issue to the right place and fix the description. >> >> The changes proposed here impact all platforms and will require discussion and cleanup. If I understand the intent, if you create a DatagramSocket or MulticastSocket that is bound to a specific local address then you want to use that to determine if the underlying socket is IPv4 or IPv6. That might be okay but multicasting normally means binding to the wildcard address so it doesn't help - I assume it only works for the test because new InetSocketAddress(port).getAddress() returns an Inet4Address so you get an IPv4 socket. It should only create a dual IPv4/IPv6 socket for this case so this is why it will break other platforms. In any case, can you look at the isXXX methods defined by sun.nio.ch.Net to see how it is handled on other platforms. > >> Yes, I agree with @AlanBateman and @msheppar . Even when we try to have an IPv4 multicast socket join an IPv4 multicast group, we still fail because the delegate that is created for an IPv4 multicast socket is IPv4/IPv6 (dual stack) in nature. AIX does not allow dual stack (IPv4/IPv6) sockets to join IPv4 multicast groups. > > The "Platform dependencies" section in the java.nio.channels.MulticastChannel (implemented by DatagramChannel) makes it clear that it is implementation specific as to whether a channel to an IPv6 socket can join an IPv4 multicast group. The recommendation is to specify the protocol family when creating the channel. Legacy DatagramSocket/MulticastSocket do not define a constructor that allows the protocol family be specified at xxxSocket create time. That issue has been there since JDK 1.4 when IPv6 support was added. I'm curious why this might be coming up with AIX now. Here, We are looking at all of the test failures mentioned in the JBS issue right now and trying to fix them . So, @AlanBateman Do you have any suggestion to fix these tests? I would be happy to look into that. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1584958570 From rriggs at openjdk.org Fri Jun 9 23:03:19 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Jun 2023 23:03:19 GMT Subject: RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3] In-Reply-To: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> References: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> Message-ID: On Sun, 9 Apr 2023 13:43:36 GMT, Markus KARG wrote: >> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of ReadableByteChannel-to-WritableByteChannel transfers, where neither Channel is a FileChannel, but including special treatment of SelectableByteChannel. >> >> *Without* this optimization, the JRE applies a loop where a temporary 16k byte array on the Java heap is used to transport the data between both channels. This implies that data is first transported from the source channel into the Java heap and then from the Java heap to the target channel. For most Channels, as these are NIO citizen, this implies two transfers between Java heap and OS resources, which is rather time consuming. As the data is in no way modified by transferTo(), the temporary allocation of valuable heap memory is just as unnecessary as both transfers to and from the heap. It makes sense to prevent the use of Java heap memory. >> >> This optimization omits the byte array on the Java heap, effectively omitting the transfers to and from that array in turn. Instead, the transfer happens directly from Channel to Channel reusing a ByteBuffer taken from the JRE's internal buffer management utility which also has a size of 16k. Both measures make the transfer more efficient, as just the very essential resources are used, but not more. >> >> Using JMH on an in-memory data transfer using custom Channels (to prevent interception by other optimizations already existing in transferTo()) it was possible to measure a 2,5% performance gain. While this does not sound much, just as the spared 16k of Java heap doesn't, we need to consider that this also means sparing GC pressure, power consumption and CO2 footprint, and we need to consider that it could be higher when using different (possibly third-party) kinds of custom Channels (as "real I/O" between heap and OS-resources is way slower than the RAM-to-RAM benchmark applied by me). As the change does not induce new, extraordinary risks compared to the existing source code, I think it is worth gaining that 2,5+ percent. Possibly there might exist some kind of scalable Java-implemented cloud service that is bound to exactly this loop and that transports very heavy traffic, those particular 2,5+ percent could be a huge amount of kWh or CO2 in absolute numbers. Even if not now, t here might be in future. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Putting the special casing for an output stream backed by a ChannelOutputStream in one place. Beyond the merits of the PR itself, beware the [sunk cost falacy](https://developerexperience.io/articles/sunk-cost). And consider the future maintenance cost of the additional code, its complexity, and interactions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13387#issuecomment-1585113257 From duke at openjdk.org Fri Jun 9 23:03:21 2023 From: duke at openjdk.org (Markus KARG) Date: Fri, 9 Jun 2023 23:03:21 GMT Subject: RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3] In-Reply-To: References: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> Message-ID: On Fri, 9 Jun 2023 20:51:57 GMT, Roger Riggs wrote: > Beyond the merits of the PR itself, beware the [sunk cost falacy](https://developerexperience.io/articles/sunk-cost). And consider the future maintenance cost of the additional code, its complexity, and interactions. I did, and still believe that it is worth it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13387#issuecomment-1585116351 From alanb at openjdk.org Sat Jun 10 06:45:46 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 10 Jun 2023 06:45:46 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> Message-ID: On Thu, 25 May 2023 07:14:19 GMT, Deepa Kumari wrote: > DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. > > On AIX, IPv6 datagramSocket can not join an IPv4 multicast group. > > These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. > > > > > Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807) @MBaesken @RealCLanger I wonder if you might have a bit of time to comment on this issue. If I read Deepa's comment correctly, she is saying that IPv6 UDP sockets on AIX cannot join IPv4 multicast groups. The spec doesn't require this but it problematic for MulticastSocket (as it has been since Java 4 when IPv6 was added). The part that I'm wondering about is what this issue might be coming up now. As I understand, SAP have supporting/maintaining/testing on AIX for a long time. Maybe your systems don't have IPv6 enabled so you never run into this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1585521766 From clanger at openjdk.org Mon Jun 12 08:59:52 2023 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 12 Jun 2023 08:59:52 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> Message-ID: On Sat, 10 Jun 2023 06:42:32 GMT, Alan Bateman wrote: > @MBaesken @RealCLanger I wonder if you might have a bit of time to comment on this issue. If I read Deepa's comment correctly, she is saying that IPv6 UDP sockets on AIX cannot join IPv4 multicast groups. The spec doesn't require this but it problematic for MulticastSocket (as it has been since Java 4 when IPv6 was added). The part that I'm wondering about is why this issue might be coming up now. As I understand, SAP have supporting/maintaining/testing on AIX for a long time. Maybe your systems don't have IPv6 enabled so you never run into this? Well, in that area we always had deviations on AIX, so definitely this rings a bell. However, since AIX was not the most important platform for us and that particular IPv6/IPv4 multicast feature didn't seem to be mission critical and wouldn't fail TCK tests, we rather resorted to excluding some tests internally, I believe. But it would be good to really resolve this compatibility/spec/documentation issue, if possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1586887143 From alanb at openjdk.org Mon Jun 12 11:12:44 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 Jun 2023 11:12:44 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> Message-ID: On Mon, 12 Jun 2023 08:57:19 GMT, Christoph Langer wrote: > Well, in that area we always had deviations on AIX, so definitely this rings a bell. However, since AIX was not the most important platform for us and that particular IPv6/IPv4 multicast feature didn't seem to be mission critical and wouldn't fail TCK tests, we rather resorted to excluding some tests internally, I believe. But it would be good to really resolve this compatibility/spec/documentation issue, if possible. Thanks. So yes, if some/all of the tests for multicasting were excluded then it helps explain why it didn't come up. The spec doesn't require that a DatgaramChannel or DatagramChannel to an IPv6 socket be capable of joining an IPv4 multicast group. So the tests in several areas might need as I don't think we've had a platform to date where it wasn't possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1587110996 From duke at openjdk.org Mon Jun 12 19:30:52 2023 From: duke at openjdk.org (Deepa Kumari) Date: Mon, 12 Jun 2023 19:30:52 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> Message-ID: <5ai8MHV2EQmFEcuMNWYM7Rz88cUl9dVnXNQolLQ3Jp8=.af5976df-6b30-4842-9b5a-7550e2fcdd0a@github.com> On Mon, 12 Jun 2023 11:09:32 GMT, Alan Bateman wrote: > > Well, in that area we always had deviations on AIX, so definitely this rings a bell. However, since AIX was not the most important platform for us and that particular IPv6/IPv4 multicast feature didn't seem to be mission critical and wouldn't fail TCK tests, we rather resorted to excluding some tests internally, I believe. But it would be good to really resolve this compatibility/spec/documentation issue, if possible. > > Thanks. So yes, if some/all of the tests for multicasting were excluded then it helps explain why it didn't come up. The spec doesn't require that a DatgaramSocket or DatagramChannel to an IPv6 socket be capable of joining an IPv4 multicast group. So the tests in several areas might need updates as I don't think we've had a platform to date where it wasn't possible. @AlanBateman , is it possible if there is a central place where the change could me made for fixing all of the multicast test cases? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1587947194 From duke at openjdk.org Tue Jun 13 03:48:04 2023 From: duke at openjdk.org (yaqsun) Date: Tue, 13 Jun 2023 03:48:04 GMT Subject: RFR: 8309778: (fs) Failed to create a symbolic link due to relative path Message-ID: Low risk, only test changes. java.nio.file.NoSuchFileException: ./name1692782213124882428/link when it is a different volume/file system. machine info: ???? ?? ?? ?? ?? ??% ??? devtmpfs devtmpfs 7.9G 0 7.9G 0% /dev tmpfs tmpfs 7.9G 245M 7.7G 4% /dev/shm tmpfs tmpfs 7.9G 893M 7.1G 12% /run tmpfs tmpfs 5.0M 16K 5.0M 1% /run/lock tmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup /dev/nvme0n1p3 xfs 42G 24G 18G 58% / /dev/nvme0n1p5 xfs 147G 25G 123G 17% /data /dev/nvme0n1p2 ext3 283M 42M 227M 16% /boot /dev/nvme0n1p1 vfat 300M 724K 299M 1% /boot/efi tmpfs tmpfs 1.6G 160K 1.6G 1% /run/user/1001 /dev/sda1 ext4 1.8T 913G 827G 53% /home/loongson/test-file ------------- Commit messages: - 8309778: [TESTBUG] Failed to create a symbolic link due to relative path Changes: https://git.openjdk.org/jdk/pull/14436/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14436&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309778 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14436/head:pull/14436 PR: https://git.openjdk.org/jdk/pull/14436 From alanb at openjdk.org Tue Jun 13 07:04:41 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Jun 2023 07:04:41 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> Message-ID: On Mon, 12 Jun 2023 11:09:32 GMT, Alan Bateman wrote: >>> @MBaesken @RealCLanger I wonder if you might have a bit of time to comment on this issue. If I read Deepa's comment correctly, she is saying that IPv6 UDP sockets on AIX cannot join IPv4 multicast groups. The spec doesn't require this but it problematic for MulticastSocket (as it has been since Java 4 when IPv6 was added). The part that I'm wondering about is why this issue might be coming up now. As I understand, SAP have supporting/maintaining/testing on AIX for a long time. Maybe your systems don't have IPv6 enabled so you never run into this? >> >> Well, in that area we always had deviations on AIX, so definitely this rings a bell. However, since AIX was not the most important platform for us and that particular IPv6/IPv4 multicast feature didn't seem to be mission critical and wouldn't fail TCK tests, we rather resorted to excluding some tests internally, I believe. But it would be good to really resolve this compatibility/spec/documentation issue, if possible. > >> Well, in that area we always had deviations on AIX, so definitely this rings a bell. However, since AIX was not the most important platform for us and that particular IPv6/IPv4 multicast feature didn't seem to be mission critical and wouldn't fail TCK tests, we rather resorted to excluding some tests internally, I believe. But it would be good to really resolve this compatibility/spec/documentation issue, if possible. > > Thanks. So yes, if some/all of the tests for multicasting were excluded then it helps explain why it didn't come up. The spec doesn't require that a DatgaramSocket or DatagramChannel to an IPv6 socket be capable of joining an IPv4 multicast group. So the tests in several areas might need updates as I don't think we've had a platform to date where it wasn't possible. > @AlanBateman , is it possible if there is a central place where the change could me made for fixing all of the multicast test cases? Your starting point is probably to exclude all of the tests that are failing. This will be tests for DatagramSocket/MulticastSocket, DatagramChannel and the tests for the JMX agent that use the discovery protocol. Once they are excluded then you can start working through the issues. For the JMX agent, then I would expect that if if the system property com.sun.management.jdp.address is configured then the protocol family is known so it should be possible to create the DatagramChannel to use that protocol family. It might so already, but you can check that. For the networking and NIO tests then you probably should look at jdk.test.lib.NetworkConfiguration. That has a number of AIX specific comments that may be out of date. After that I think you will need to work through the tests one by one. Between NetworkConfiguration and jdk.test.lib.net.IPSupport, I would expect you have all the infrastructure needed for the tests to not attempt to join IPv4 multicast groups when IPSupport.hasIPv6() is true. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1588666107 From alanb at openjdk.org Tue Jun 13 07:26:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Jun 2023 07:26:50 GMT Subject: RFR: 8308593: Add Keepalive Extended Socket Options Support for Windows In-Reply-To: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com> References: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com> Message-ID: <9Qc7jA1I12yBiwskkvXi_2Y_IlEymkkvH2-u29w_kns=.71e358c2-4d4e-4ef9-a71c-17a6656761bb@github.com> On Tue, 30 May 2023 22:46:05 GMT, Terry Chow wrote: > The PR adds support for setting the keepalive extended socket options on Windows. The implemented native code uses the SIO_KEEPALIVE_VALS control code, which is how keepalive values are set on Windows and so there are a few caveats. > > 1. The keepalive time and keepalive interval must both be set at the same time. In the implementation, a new SioKeepAlive class and ExtendedSocketOptions is created to capture this behaviour for Windows only. Keepalive enablement must also be configured when using SIO_KEEPALIVE_VALS, and so by default when setting keepalive time and keepalive interval, > keepalive will automatically be enabled. > > [SIO_KEEPALIVE_VALS doc](https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals) > > 2. It doesn't seem possible to acquire the Keepalive time and keepalive interval values on Windows. So, the implementation doesn't support acquiring the values. > > https://stackoverflow.com/questions/14197347/how-to-query-socket-keep-alive-values-using-winsock/14198462#14198462 > https://stackoverflow.com/questions/18391341/reading-sio-keepalive-vals-fields-on-a-windows-socket-for-keepalive-idle-and-in > > 3. Keepalive probes are not supported. On Windows Vista and later, the number of keep-alive probes is set to 10 and cannot be changed. > > [SIO_KEEPALIVE_VALS Remarks](https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals#remarks) > > For testing, I've updated the existing keepalive tests. But, since it's not possible to acquire the keepalive values on Windows to verify, I've indirectly tested setting the keepalive values by confirming keepalive is enabled where possible (since keepalive is enabled also when keepalive values are set). In the discussion on net-dev/nio-dev, Daniel Jeli?ski pointed out that Windows does have TCP_KEEPIDLE and TCP_KEEPINTVL since Windows 10 version 1709. So I assume this PR can be returned to closed or re-returned to draft while the implementation changes are developed to make use of these socket options. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14232#issuecomment-1588700452 From alanb at openjdk.org Tue Jun 13 08:39:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Jun 2023 08:39:55 GMT Subject: RFR: 8309778: (fs) Failed to create a symbolic link due to relative path In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 03:40:53 GMT, yaqsun wrote: > Low risk, only test changes. > java.nio.file.NoSuchFileException: ./name1692782213124882428/link when it is a different volume/file system. > machine info: > > ???? ?? ?? ?? ?? ??% ??? > devtmpfs devtmpfs 7.9G 0 7.9G 0% /dev > tmpfs tmpfs 7.9G 245M 7.7G 4% /dev/shm > tmpfs tmpfs 7.9G 893M 7.1G 12% /run > tmpfs tmpfs 5.0M 16K 5.0M 1% /run/lock > tmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup > /dev/nvme0n1p3 xfs 42G 24G 18G 58% / > /dev/nvme0n1p5 xfs 147G 25G 123G 17% /data > /dev/nvme0n1p2 ext3 283M 42M 227M 16% /boot > /dev/nvme0n1p1 vfat 300M 724K 299M 1% /boot/efi > tmpfs tmpfs 1.6G 160K 1.6G 1% /run/user/1001 > /dev/sda1 ext4 1.8T 913G 827G 53% /home/loongson/test-file The CopyAndMove test will re-run the copy/move tests when the jtreg work directory is on a different file system to tmp file system. It looks like this broke at some point but may not have been noticed. I've changed the JBS issue to make it clearer what this issue is about. Do you mind renaming the PR too? test/jdk/java/nio/file/Files/CopyAndMove.java line 65: > 63: // be a different volume/file system and so improve test coverage. > 64: String testDir = System.getProperty("test.dir", "."); > 65: Path dir2 = TestUtil.createTemporaryDirectory(testDir).toAbsolutePath(); This change looks okay, do you mind update the Oracle copyright header end date to 2023 too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14436#issuecomment-1588821999 PR Review Comment: https://git.openjdk.org/jdk/pull/14436#discussion_r1227746903 From alanb at openjdk.org Tue Jun 13 09:00:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Jun 2023 09:00:50 GMT Subject: RFR: 8309778: (fs) Failed to create a symbolic link due to relative path In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 03:40:53 GMT, yaqsun wrote: > Low risk, only test changes. > java.nio.file.NoSuchFileException: ./name1692782213124882428/link when it is a different volume/file system. > machine info: > > ???? ?? ?? ?? ?? ??% ??? > devtmpfs devtmpfs 7.9G 0 7.9G 0% /dev > tmpfs tmpfs 7.9G 245M 7.7G 4% /dev/shm > tmpfs tmpfs 7.9G 893M 7.1G 12% /run > tmpfs tmpfs 5.0M 16K 5.0M 1% /run/lock > tmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup > /dev/nvme0n1p3 xfs 42G 24G 18G 58% / > /dev/nvme0n1p5 xfs 147G 25G 123G 17% /data > /dev/nvme0n1p2 ext3 283M 42M 227M 16% /boot > /dev/nvme0n1p1 vfat 300M 724K 299M 1% /boot/efi > tmpfs tmpfs 1.6G 160K 1.6G 1% /run/user/1001 > /dev/sda1 ext4 1.8T 913G 827G 53% /home/loongson/test-file Would it be possible to try this an alternative fix? diff --git a/test/jdk/java/nio/file/Files/CopyAndMove.java b/test/jdk/java/nio/file/Files/CopyAndMove.java index 8f6e7742356..b028c7d4864 100644 --- a/test/jdk/java/nio/file/Files/CopyAndMove.java +++ b/test/jdk/java/nio/file/Files/CopyAndMove.java @@ -909,7 +909,7 @@ public class CopyAndMove { if (supportsLinks) { source = createSourceFile(dir1); link = dir1.resolve("link"); - createSymbolicLink(link, source); + createSymbolicLink(link, source.getFileName()); target = getTargetFile(dir2); copyAndVerify(link, target); delete(link); ------------- PR Comment: https://git.openjdk.org/jdk/pull/14436#issuecomment-1588854019 From duke at openjdk.org Tue Jun 13 09:45:59 2023 From: duke at openjdk.org (yaqsun) Date: Tue, 13 Jun 2023 09:45:59 GMT Subject: RFR: 8309778: (fs) Failed to create a symbolic link due to relative path [v2] In-Reply-To: References: Message-ID: > Low risk, only test changes. > java.nio.file.NoSuchFileException: ./name1692782213124882428/link when it is a different volume/file system. > machine info: > > ???? ?? ?? ?? ?? ??% ??? > devtmpfs devtmpfs 7.9G 0 7.9G 0% /dev > tmpfs tmpfs 7.9G 245M 7.7G 4% /dev/shm > tmpfs tmpfs 7.9G 893M 7.1G 12% /run > tmpfs tmpfs 5.0M 16K 5.0M 1% /run/lock > tmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup > /dev/nvme0n1p3 xfs 42G 24G 18G 58% / > /dev/nvme0n1p5 xfs 147G 25G 123G 17% /data > /dev/nvme0n1p2 ext3 283M 42M 227M 16% /boot > /dev/nvme0n1p1 vfat 300M 724K 299M 1% /boot/efi > tmpfs tmpfs 1.6G 160K 1.6G 1% /run/user/1001 > /dev/sda1 ext4 1.8T 913G 827G 53% /home/loongson/test-file yaqsun has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14436/files - new: https://git.openjdk.org/jdk/pull/14436/files/8f095202..83cd31e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14436&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14436&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14436/head:pull/14436 PR: https://git.openjdk.org/jdk/pull/14436 From duke at openjdk.org Wed Jun 14 02:38:58 2023 From: duke at openjdk.org (yaqsun) Date: Wed, 14 Jun 2023 02:38:58 GMT Subject: RFR: 8309778: (fs) Failed to create a symbolic link due to relative path [v3] In-Reply-To: References: Message-ID: <90ytiAPLSiqxKGTn6WV3Tfhb4eJ2KoNtsHlbFwLRhN4=.08b97f9b-fe8c-486a-951f-29069f375542@github.com> > Low risk, only test changes. > java.nio.file.NoSuchFileException: ./name1692782213124882428/link when it is a different volume/file system. > machine info: > > ???? ?? ?? ?? ?? ??% ??? > devtmpfs devtmpfs 7.9G 0 7.9G 0% /dev > tmpfs tmpfs 7.9G 245M 7.7G 4% /dev/shm > tmpfs tmpfs 7.9G 893M 7.1G 12% /run > tmpfs tmpfs 5.0M 16K 5.0M 1% /run/lock > tmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup > /dev/nvme0n1p3 xfs 42G 24G 18G 58% / > /dev/nvme0n1p5 xfs 147G 25G 123G 17% /data > /dev/nvme0n1p2 ext3 283M 42M 227M 16% /boot > /dev/nvme0n1p1 vfat 300M 724K 299M 1% /boot/efi > tmpfs tmpfs 1.6G 160K 1.6G 1% /run/user/1001 > /dev/sda1 ext4 1.8T 913G 827G 53% /home/loongson/test-file yaqsun has updated the pull request incrementally with one additional commit since the last revision: 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14436/files - new: https://git.openjdk.org/jdk/pull/14436/files/83cd31e1..bc2e7355 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14436&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14436&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14436/head:pull/14436 PR: https://git.openjdk.org/jdk/pull/14436 From alanb at openjdk.org Wed Jun 14 11:16:59 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jun 2023 11:16:59 GMT Subject: RFR: 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory [v3] In-Reply-To: <90ytiAPLSiqxKGTn6WV3Tfhb4eJ2KoNtsHlbFwLRhN4=.08b97f9b-fe8c-486a-951f-29069f375542@github.com> References: <90ytiAPLSiqxKGTn6WV3Tfhb4eJ2KoNtsHlbFwLRhN4=.08b97f9b-fe8c-486a-951f-29069f375542@github.com> Message-ID: <1bE931lz-j7MBimGG7fBMB6aWomWFVFnrajAenBPPg8=.a714e86d-8636-4567-99ba-4315dfa0f25e@github.com> On Wed, 14 Jun 2023 02:38:58 GMT, yaqsun wrote: >> Low risk, only test changes. >> java.nio.file.NoSuchFileException: ./name1692782213124882428/link when it is a different volume/file system. >> machine info: >> >> ???? ?? ?? ?? ?? ??% ??? >> devtmpfs devtmpfs 7.9G 0 7.9G 0% /dev >> tmpfs tmpfs 7.9G 245M 7.7G 4% /dev/shm >> tmpfs tmpfs 7.9G 893M 7.1G 12% /run >> tmpfs tmpfs 5.0M 16K 5.0M 1% /run/lock >> tmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup >> /dev/nvme0n1p3 xfs 42G 24G 18G 58% / >> /dev/nvme0n1p5 xfs 147G 25G 123G 17% /data >> /dev/nvme0n1p2 ext3 283M 42M 227M 16% /boot >> /dev/nvme0n1p1 vfat 300M 724K 299M 1% /boot/efi >> tmpfs tmpfs 1.6G 160K 1.6G 1% /run/user/1001 >> /dev/sda1 ext4 1.8T 913G 827G 53% /home/loongson/test-file > > yaqsun has updated the pull request incrementally with one additional commit since the last revision: > > 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory Looks okay. I'll assume you will update the copyright year on the test before you integrate. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14436#pullrequestreview-1479138444 From naoto at openjdk.org Wed Jun 14 16:54:02 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 14 Jun 2023 16:54:02 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself Message-ID: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> Adding themselves into their `contains()` method will fix it. ------------- Commit messages: - 8167252: Some of Charset.availableCharsets() does not contain itself Changes: https://git.openjdk.org/jdk/pull/14473/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14473&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8167252 Stats: 34 lines in 4 files changed: 28 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14473.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14473/head:pull/14473 PR: https://git.openjdk.org/jdk/pull/14473 From bpb at openjdk.org Wed Jun 14 17:01:56 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 Jun 2023 17:01:56 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> Message-ID: On Wed, 14 Jun 2023 16:47:40 GMT, Naoto Sato wrote: > Adding themselves into their `contains()` method will fix it. Looks all right. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1479929263 From alanb at openjdk.org Wed Jun 14 17:15:13 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jun 2023 17:15:13 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> Message-ID: On Wed, 14 Jun 2023 16:47:40 GMT, Naoto Sato wrote: > Adding themselves into their `contains()` method will fix it. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1479944770 From iris at openjdk.org Wed Jun 14 17:15:14 2023 From: iris at openjdk.org (Iris Clark) Date: Wed, 14 Jun 2023 17:15:14 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> Message-ID: <2kfcSeSvGvUD7EOTxsn1SZ5Oif1bBd1N79t_7RK4dHY=.80f0650a-8b1b-44bc-9102-575dfd00f08a@github.com> On Wed, 14 Jun 2023 16:47:40 GMT, Naoto Sato wrote: > Adding themselves into their `contains()` method will fix it. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1479949748 From lancea at openjdk.org Wed Jun 14 17:18:58 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 14 Jun 2023 17:18:58 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> Message-ID: On Wed, 14 Jun 2023 16:47:40 GMT, Naoto Sato wrote: > Adding themselves into their `contains()` method will fix it. Changes look fine over all. It might be worth considering updating this to use junit at some point as a separate clean up activity as it could further streamline the test test/jdk/java/nio/charset/Charset/Contains.java line 108: > 106: } > 107: > 108: static void selfContainmentTest() { Be nice to add a comment regarding the purpose of the test ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1479953238 PR Review Comment: https://git.openjdk.org/jdk/pull/14473#discussion_r1229937043 From alanb at openjdk.org Wed Jun 14 17:22:58 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jun 2023 17:22:58 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself In-Reply-To: References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> Message-ID: <2HdpYQwGcgeMZTqQY3zIMPch8KYRJbxmdQlNHzIWoLk=.f5449964-d30b-4a5f-b4f4-76faaa341bdb@github.com> On Wed, 14 Jun 2023 17:14:08 GMT, Lance Andersen wrote: >> Adding themselves into their `contains()` method will fix it. > > test/jdk/java/nio/charset/Charset/Contains.java line 108: > >> 106: } >> 107: >> 108: static void selfContainmentTest() { > > Be nice to add a comment regarding the purpose of the test The spec is that Charset::contains return true for self so maybe it could be renamed to containsSelfTest, might help with the understanding the purpose (along with a comment) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14473#discussion_r1229943556 From naoto at openjdk.org Wed Jun 14 17:42:57 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 14 Jun 2023 17:42:57 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself In-Reply-To: <2HdpYQwGcgeMZTqQY3zIMPch8KYRJbxmdQlNHzIWoLk=.f5449964-d30b-4a5f-b4f4-76faaa341bdb@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> <2HdpYQwGcgeMZTqQY3zIMPch8KYRJbxmdQlNHzIWoLk=.f5449964-d30b-4a5f-b4f4-76faaa341bdb@github.com> Message-ID: On Wed, 14 Jun 2023 17:20:31 GMT, Alan Bateman wrote: >> test/jdk/java/nio/charset/Charset/Contains.java line 108: >> >>> 106: } >>> 107: >>> 108: static void selfContainmentTest() { >> >> Be nice to add a comment regarding the purpose of the test > > The spec is that Charset::contains return true for self so maybe it could be renamed to containsSelfTest, might help with the understanding the purpose (along with a comment) Good point. Will address these in the next iteration ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14473#discussion_r1229964387 From naoto at openjdk.org Wed Jun 14 18:08:34 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 14 Jun 2023 18:08:34 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself [v2] In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> Message-ID: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> > Adding themselves into their `contains()` method will fix it. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Refined the test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14473/files - new: https://git.openjdk.org/jdk/pull/14473/files/89899160..bea24165 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14473&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14473&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14473.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14473/head:pull/14473 PR: https://git.openjdk.org/jdk/pull/14473 From alanb at openjdk.org Wed Jun 14 18:12:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jun 2023 18:12:57 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself [v2] In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> Message-ID: On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato wrote: >> Adding themselves into their `contains()` method will fix it. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refined the test Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1480039785 From lancea at openjdk.org Wed Jun 14 18:36:59 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 14 Jun 2023 18:36:59 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself [v2] In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> Message-ID: <5IHATGaFRMSrVD-OSG1ol95xp18k8mef-iy0QhlJQwo=.ce3997b9-1d4c-49ee-a672-9e0e2dc9ba91@github.com> On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato wrote: >> Adding themselves into their `contains()` method will fix it. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refined the test Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1480078751 From bpb at openjdk.org Wed Jun 14 18:50:57 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 Jun 2023 18:50:57 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself [v2] In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> Message-ID: On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato wrote: >> Adding themselves into their `contains()` method will fix it. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refined the test Re-approved. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1480096863 From iris at openjdk.org Wed Jun 14 19:19:13 2023 From: iris at openjdk.org (Iris Clark) Date: Wed, 14 Jun 2023 19:19:13 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself [v2] In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> Message-ID: On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato wrote: >> Adding themselves into their `contains()` method will fix it. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refined the test Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1480141268 From duke at openjdk.org Thu Jun 15 01:19:38 2023 From: duke at openjdk.org (yaqsun) Date: Thu, 15 Jun 2023 01:19:38 GMT Subject: RFR: 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory [v4] In-Reply-To: References: Message-ID: > Low risk, only test changes. > java.nio.file.NoSuchFileException: ./name1692782213124882428/link when it is a different volume/file system. > machine info: > > ???? ?? ?? ?? ?? ??% ??? > devtmpfs devtmpfs 7.9G 0 7.9G 0% /dev > tmpfs tmpfs 7.9G 245M 7.7G 4% /dev/shm > tmpfs tmpfs 7.9G 893M 7.1G 12% /run > tmpfs tmpfs 5.0M 16K 5.0M 1% /run/lock > tmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup > /dev/nvme0n1p3 xfs 42G 24G 18G 58% / > /dev/nvme0n1p5 xfs 147G 25G 123G 17% /data > /dev/nvme0n1p2 ext3 283M 42M 227M 16% /boot > /dev/nvme0n1p1 vfat 300M 724K 299M 1% /boot/efi > tmpfs tmpfs 1.6G 160K 1.6G 1% /run/user/1001 > /dev/sda1 ext4 1.8T 913G 827G 53% /home/loongson/test-file yaqsun has updated the pull request incrementally with one additional commit since the last revision: 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14436/files - new: https://git.openjdk.org/jdk/pull/14436/files/bc2e7355..ec6a05c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14436&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14436&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14436.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14436/head:pull/14436 PR: https://git.openjdk.org/jdk/pull/14436 From alanb at openjdk.org Thu Jun 15 04:49:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Jun 2023 04:49:05 GMT Subject: RFR: 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory [v4] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 01:19:38 GMT, yaqsun wrote: >> Low risk, only test changes. >> java.nio.file.NoSuchFileException: ./name1692782213124882428/link when it is a different volume/file system. >> machine info: >> >> ???? ?? ?? ?? ?? ??% ??? >> devtmpfs devtmpfs 7.9G 0 7.9G 0% /dev >> tmpfs tmpfs 7.9G 245M 7.7G 4% /dev/shm >> tmpfs tmpfs 7.9G 893M 7.1G 12% /run >> tmpfs tmpfs 5.0M 16K 5.0M 1% /run/lock >> tmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup >> /dev/nvme0n1p3 xfs 42G 24G 18G 58% / >> /dev/nvme0n1p5 xfs 147G 25G 123G 17% /data >> /dev/nvme0n1p2 ext3 283M 42M 227M 16% /boot >> /dev/nvme0n1p1 vfat 300M 724K 299M 1% /boot/efi >> tmpfs tmpfs 1.6G 160K 1.6G 1% /run/user/1001 >> /dev/sda1 ext4 1.8T 913G 827G 53% /home/loongson/test-file > > yaqsun has updated the pull request incrementally with one additional commit since the last revision: > > 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14436#pullrequestreview-1480665121 From jpai at openjdk.org Thu Jun 15 06:21:58 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 15 Jun 2023 06:21:58 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself [v2] In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> Message-ID: On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato wrote: >> Adding themselves into their `contains()` method will fix it. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refined the test Hello Naoto, should `sun.util.PropertyResourceBundleCharset` be fixed too? Its `contains()` currently just returns `false`. Then there is `sun.font.X11Johab` in `java.desktop` module whose `contains()` appears to have a typo and is checking against an unrelated `X11GB18030_1` instance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14473#issuecomment-1592434256 From alanb at openjdk.org Thu Jun 15 06:45:59 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Jun 2023 06:45:59 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself [v2] In-Reply-To: References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> Message-ID: On Thu, 15 Jun 2023 06:19:09 GMT, Jaikiran Pai wrote: > Hello Naoto, should `sun.util.PropertyResourceBundleCharset` be fixed too? This is JDK internal, it shouldn't leak out via the APIs. If there is a way for it to leak out then it would require a compliant contains method but I suspect it's internal only. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14473#issuecomment-1592456040 From jpai at openjdk.org Thu Jun 15 07:23:59 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 15 Jun 2023 07:23:59 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself [v2] In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> Message-ID: On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato wrote: >> Adding themselves into their `contains()` method will fix it. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refined the test Marked as reviewed by jpai (Reviewer). Hello Alan, > > Hello Naoto, should `sun.util.PropertyResourceBundleCharset` be fixed too? > > This is JDK internal, it shouldn't leak out via the APIs. If there is a way for it to leak out then it would require a compliant contains method but I suspect it's internal only. You are right this is an internal class (I just found these by checking which classes extend `Charset`). I now paid a closer attention to the title of this issue and this is more about the Charset(s) that are returned through the public API, so I think it's OK to leave these internal classes as-is at least in this PR. ------------- PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1480864774 PR Comment: https://git.openjdk.org/jdk/pull/14473#issuecomment-1592498880 From michaelm at openjdk.org Thu Jun 15 10:54:32 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 15 Jun 2023 10:54:32 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups Message-ID: Hi, Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. The equivalent behavior has already been implemented for IPv4 sockets. Thanks, Michael. ------------- Commit messages: - added test comment - Merge branch 'master' into ipv6opt - test fix - fix whitespace - added test - initial impl Changes: https://git.openjdk.org/jdk/pull/14491/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8241800 Stats: 184 lines in 2 files changed: 184 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14491/head:pull/14491 PR: https://git.openjdk.org/jdk/pull/14491 From alanb at openjdk.org Thu Jun 15 11:25:00 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Jun 2023 11:25:00 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 10:47:58 GMT, Michael McMahon wrote: > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. src/java.base/unix/native/libnio/ch/Net.c line 310: > 308: close(fd); > 309: return -1; > 310: } It might be better to move this to just below the attempt to set IPV6_MULTICAST_HOPS as that code only runs for IPv6 datagrams. That said, I'm a bit concerned that this will fail on older kernels. Are you sure the error is ENOPROTOOPT? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1230860122 From msheppar at openjdk.org Thu Jun 15 11:30:57 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 15 Jun 2023 11:30:57 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 10:47:58 GMT, Michael McMahon wrote: > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. so is it the case that for INET6 two call setsockopt calls need to be called one for IP_MULTICAST_ALL and one for IPV6_MULTICAST_ALL. IFF that is the case I think two conditional blocks, on the domain, to emphasize this would be clearer and convey such semantics more cleanly if (domain == AF_INET6) { .... if((setsockopt(fd, IPPROTO_IPV6, IP_MULTICAST_ALL, (char*)&arg, sizeof(arg)) < 0) && ... { .... } if((setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_ALL, (char*)&arg, sizeof(arg)) < 0) && ... { .... } } else { if((setsockopt(fd, IPPROTO_IP, IP_MULTICAST_ALL, (char*)&arg, sizeof(arg)) < 0) && ... { .... } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/14491#issuecomment-1592868150 From michaelm at openjdk.org Thu Jun 15 11:30:58 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 15 Jun 2023 11:30:58 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups In-Reply-To: References: Message-ID: <2YPfMs0kmk4Aza5BAnnWlll-kOzerbHYsmr1paWHzX4=.db6f16c4-2bec-432e-b1cd-fcab75b10c13@github.com> On Thu, 15 Jun 2023 11:21:52 GMT, Alan Bateman wrote: >> Hi, >> >> Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. >> >> The equivalent behavior has already been implemented for IPv4 sockets. >> >> Thanks, >> Michael. > > src/java.base/unix/native/libnio/ch/Net.c line 310: > >> 308: close(fd); >> 309: return -1; >> 310: } > > It might be better to move this to just below the attempt to set IPV6_MULTICAST_HOPS as that code only runs for IPv6 datagrams. > > That said, I'm a bit concerned that this will fail on older kernels. Are you sure the error is ENOPROTOOPT? Yes, the error is the same as for the IPv4 option. If you like I can change the test to set the option and check an exception is not thrown in those cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1230865928 From alanb at openjdk.org Thu Jun 15 11:34:58 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Jun 2023 11:34:58 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups In-Reply-To: <2YPfMs0kmk4Aza5BAnnWlll-kOzerbHYsmr1paWHzX4=.db6f16c4-2bec-432e-b1cd-fcab75b10c13@github.com> References: <2YPfMs0kmk4Aza5BAnnWlll-kOzerbHYsmr1paWHzX4=.db6f16c4-2bec-432e-b1cd-fcab75b10c13@github.com> Message-ID: On Thu, 15 Jun 2023 11:27:48 GMT, Michael McMahon wrote: > Yes, the error is the same as for the IPv4 option. If you like I can change the test to set the option and check an exception is not thrown in those cases. If you are confident that ENOPROTOOPT is returned by older kernels then okay. Also just to double check, IPV6_MULTICAST_ALL applied only to IPv6 multicast datagrams, we have to continue to set IP_MULTICAST_ALL for cases where the IPv6 socket joins an IPv4 multicast group. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1230870994 From michaelm at openjdk.org Thu Jun 15 11:34:56 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 15 Jun 2023 11:34:56 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 10:47:58 GMT, Michael McMahon wrote: > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. > It's certainly the case that the IPv4 option can be called on AF_INET6 sockets but only affects the IPv4 stack. Which suggests the IPv6 option only affects the IPv6 stack. I'll see if I can confirm that is true. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14491#issuecomment-1592872562 From michaelm at openjdk.org Thu Jun 15 15:05:19 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 15 Jun 2023 15:05:19 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v2] In-Reply-To: References: Message-ID: > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. Michael McMahon has updated the pull request incrementally with two additional commits since the last revision: - typo - review update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14491/files - new: https://git.openjdk.org/jdk/pull/14491/files/e45808f8..37b4e8c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=00-01 Stats: 29 lines in 2 files changed: 18 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14491/head:pull/14491 PR: https://git.openjdk.org/jdk/pull/14491 From michaelm at openjdk.org Thu Jun 15 15:20:57 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 15 Jun 2023 15:20:57 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 11:32:45 GMT, Michael McMahon wrote: > > > > It's certainly the case that the IPv4 option can be called on AF_INET6 sockets but only affects the IPv4 stack. Which suggests the IPv6 option only affects the IPv6 stack. I'll see if I can confirm that is true. I just checked and the two options are independent of each other, applying only to the IPv4 stack and IPv6 stack respectively. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14491#issuecomment-1593271468 From alanb at openjdk.org Thu Jun 15 16:15:59 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Jun 2023 16:15:59 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 15:05:19 GMT, Michael McMahon wrote: >> Hi, >> >> Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. >> >> The equivalent behavior has already been implemented for IPv4 sockets. >> >> Thanks, >> Michael. > > Michael McMahon has updated the pull request incrementally with two additional commits since the last revision: > > - typo > - review update src/java.base/unix/native/libnio/ch/Net.c line 325: > 323: close(fd); > 324: return -1; > 325: } This implementation change looks okay, assuming ENOPROTOOPT on older kernels. I haven't had time to study the test yet, tricky scenario to test reliably. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1231251127 From naoto at openjdk.org Thu Jun 15 16:37:12 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Jun 2023 16:37:12 GMT Subject: RFR: 8167252: Some of Charset.availableCharsets() does not contain itself [v2] In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com> Message-ID: On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato wrote: >> Adding themselves into their `contains()` method will fix it. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refined the test Thanks for the review, Jai. As to `PropertyResourceBundleCharset`, yes it is an internal implementation as Alan mentioned, to auto detect UTF-8/ISO-8859-1, so even though `contains()` does not include itself, it is fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14473#issuecomment-1593385179 From naoto at openjdk.org Thu Jun 15 16:37:15 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Jun 2023 16:37:15 GMT Subject: Integrated: 8167252: Some of Charset.availableCharsets() does not contain itself In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com> Message-ID: On Wed, 14 Jun 2023 16:47:40 GMT, Naoto Sato wrote: > Adding themselves into their `contains()` method will fix it. This pull request has now been integrated. Changeset: 3eeb681a Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/3eeb681a0de87baa12b6eac5966e7f707b76c8bf Stats: 37 lines in 4 files changed: 31 ins; 0 del; 6 mod 8167252: Some of Charset.availableCharsets() does not contain itself Reviewed-by: bpb, alanb, iris, lancea, jpai ------------- PR: https://git.openjdk.org/jdk/pull/14473 From jlu at openjdk.org Thu Jun 15 19:49:37 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 Jun 2023 19:49:37 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit Message-ID: As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything. ------------- Commit messages: - Merge master and fix conflicts in Contains.java - Refactor CharsetContainmentTest.java - Remove unusued JUnit import in RegisteredCharsets.java - Refactor contains.java - Move bug id for default charset test - Add bug id to EncDec.java - Do not use wildcard import in IllegalCharsetName.java - Refactor RegisteredCharsets.java - Move default charset test to IllegalCharsetName.java - Refactor EncDec test to use JUnit - ... and 5 more: https://git.openjdk.org/jdk/compare/3e0bbd29...be352ca2 Changes: https://git.openjdk.org/jdk/pull/14500/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14500&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310049 Stats: 2076 lines in 9 files changed: 366 ins; 447 del; 1263 mod Patch: https://git.openjdk.org/jdk/pull/14500.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14500/head:pull/14500 PR: https://git.openjdk.org/jdk/pull/14500 From lancea at openjdk.org Thu Jun 15 19:58:11 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 15 Jun 2023 19:58:11 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 19:42:56 GMT, Justin Lu wrote: > As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. > > In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything. Thanks for starting this migration/refactor. I would use this as an opportunity to add additional comments introducing the tests and the relevant parameterized lists et al test/jdk/java/nio/charset/Charset/AvailableCharsetNames.java line 25: > 23: > 24: /* @test > 25: * @bug 4422044 8310049 As this is just a refactor, I don't think you need the bug number for converting to junit ------------- PR Review: https://git.openjdk.org/jdk/pull/14500#pullrequestreview-1482287594 PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231472262 From jlu at openjdk.org Thu Jun 15 20:04:21 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 Jun 2023 20:04:21 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v2] In-Reply-To: References: Message-ID: > As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. > > In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Review: Refactoring does not require bugID in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14500/files - new: https://git.openjdk.org/jdk/pull/14500/files/be352ca2..eb374d64 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14500&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14500&range=00-01 Stats: 6 lines in 6 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14500.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14500/head:pull/14500 PR: https://git.openjdk.org/jdk/pull/14500 From jlu at openjdk.org Thu Jun 15 20:04:24 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 Jun 2023 20:04:24 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 19:52:55 GMT, Lance Andersen wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Review: Refactoring does not require bugID in test > > test/jdk/java/nio/charset/Charset/AvailableCharsetNames.java line 25: > >> 23: >> 24: /* @test >> 25: * @bug 4422044 8310049 > > As this is just a refactor, I don't think you need the bug number for converting to junit Fixed, in this file and the others ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231478728 From jlu at openjdk.org Thu Jun 15 20:48:38 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 Jun 2023 20:48:38 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v3] In-Reply-To: References: Message-ID: > As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. > > In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything. Justin Lu has updated the pull request incrementally with eight additional commits since the last revision: - Review: Clarify RegisteredCharsets.java and add comments to test methods - Minor cleanup - Refactor IllegalCharsetName.java to use method source - Update EncDec.java to be more informative + cautious - Update data source: other -> standard Charsets - Review: Add comments to Contains.java to explain each test - Review: Add comment for test in AvailableCharsetNames.java - Review: Make CharsetContainmentTest.java data source and test method more clear ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14500/files - new: https://git.openjdk.org/jdk/pull/14500/files/eb374d64..6c7a8d05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14500&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14500&range=01-02 Stats: 108 lines in 6 files changed: 70 ins; 14 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/14500.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14500/head:pull/14500 PR: https://git.openjdk.org/jdk/pull/14500 From naoto at openjdk.org Thu Jun 15 22:29:06 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Jun 2023 22:29:06 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 20:48:38 GMT, Justin Lu wrote: >> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. >> >> In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything. > > Justin Lu has updated the pull request incrementally with eight additional commits since the last revision: > > - Review: Clarify RegisteredCharsets.java and add comments to test methods > - Minor cleanup > - Refactor IllegalCharsetName.java to use method source > - Update EncDec.java to be more informative + cautious > - Update data source: other -> standard Charsets > - Review: Add comments to Contains.java to explain each test > - Review: Add comment for test in AvailableCharsetNames.java > - Review: Make CharsetContainmentTest.java data source and test method more clear Thanks for the clean-up. Some comments follow: test/jdk/java/nio/charset/Charset/Contains.java line 51: > 49: @ParameterizedTest > 50: @MethodSource("standardCharsets") > 51: public void standardCharsetsTest(Charset containerCs, Charset cs, boolean cont){ `ISO-8859-15` and `CP1252` are not `StandardCharsets` so renaming the method to standardCharsetsTest seems incorrect. test/jdk/java/nio/charset/Charset/Default.java line 1: > 1: /* This class is used in `DefaultCharsetTest` so don't remove it. test/jdk/java/nio/charset/Charset/IllegalCharsetName.java line 51: > 49: assertThrows(UnsupportedCharsetException.class, > 50: () -> Charset.forName("default")); > 51: } Seems incorrect to merge this test into `IllegalCharsetName.java` because it is throwing `UnsupportedCharsetException`. ------------- PR Review: https://git.openjdk.org/jdk/pull/14500#pullrequestreview-1482442857 PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231572797 PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231585756 PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231594567 From jlu at openjdk.org Thu Jun 15 23:09:24 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 Jun 2023 23:09:24 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v4] In-Reply-To: References: Message-ID: > As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. > > In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything. Justin Lu has updated the pull request incrementally with three additional commits since the last revision: - Review: Move default test back to RegisteredCharsets.java - Review: rename standard charsets test - Revert "Remove Default test" This reverts commit 346cb4c050adb8bd8a3cb942e25a98484703b997. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14500/files - new: https://git.openjdk.org/jdk/pull/14500/files/6c7a8d05..6a39ceab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14500&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14500&range=02-03 Stats: 61 lines in 4 files changed: 46 ins; 8 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14500.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14500/head:pull/14500 PR: https://git.openjdk.org/jdk/pull/14500 From jlu at openjdk.org Thu Jun 15 23:09:24 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 Jun 2023 23:09:24 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 21:58:56 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with eight additional commits since the last revision: >> >> - Review: Clarify RegisteredCharsets.java and add comments to test methods >> - Minor cleanup >> - Refactor IllegalCharsetName.java to use method source >> - Update EncDec.java to be more informative + cautious >> - Update data source: other -> standard Charsets >> - Review: Add comments to Contains.java to explain each test >> - Review: Add comment for test in AvailableCharsetNames.java >> - Review: Make CharsetContainmentTest.java data source and test method more clear > > test/jdk/java/nio/charset/Charset/Contains.java line 51: > >> 49: @ParameterizedTest >> 50: @MethodSource("standardCharsets") >> 51: public void standardCharsetsTest(Charset containerCs, Charset cs, boolean cont){ > > `ISO-8859-15` and `CP1252` are not `StandardCharsets` so renaming the method to standardCharsetsTest seems incorrect. Did not realize, thank you. I simply renamed it to charsets (as I am not sure if those tested are supposed to represent a particular group, or if they are just random). > test/jdk/java/nio/charset/Charset/IllegalCharsetName.java line 51: > >> 49: assertThrows(UnsupportedCharsetException.class, >> 50: () -> Charset.forName("default")); >> 51: } > > Seems incorrect to merge this test into `IllegalCharsetName.java` because it is throwing `UnsupportedCharsetException`. I moved it back to RegisteredCharsets.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231612571 PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231612904 From jlu at openjdk.org Thu Jun 15 23:09:25 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 Jun 2023 23:09:25 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v4] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 22:11:31 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with three additional commits since the last revision: >> >> - Review: Move default test back to RegisteredCharsets.java >> - Review: rename standard charsets test >> - Revert "Remove Default test" >> >> This reverts commit 346cb4c050adb8bd8a3cb942e25a98484703b997. > > test/jdk/java/nio/charset/Charset/Default.java line 1: > >> (failed to retrieve contents of file, check the PR for context) > This class is used in `DefaultCharsetTest` so don't remove it. Fixed, thank you ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231612681 From alanb at openjdk.org Fri Jun 16 05:08:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jun 2023 05:08:21 GMT Subject: RFR: 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory [v4] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 01:19:38 GMT, yaqsun wrote: >> Low risk, only test changes. >> java.nio.file.NoSuchFileException: ./name1692782213124882428/link when it is a different volume/file system. >> machine info: >> >> ???? ?? ?? ?? ?? ??% ??? >> devtmpfs devtmpfs 7.9G 0 7.9G 0% /dev >> tmpfs tmpfs 7.9G 245M 7.7G 4% /dev/shm >> tmpfs tmpfs 7.9G 893M 7.1G 12% /run >> tmpfs tmpfs 5.0M 16K 5.0M 1% /run/lock >> tmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup >> /dev/nvme0n1p3 xfs 42G 24G 18G 58% / >> /dev/nvme0n1p5 xfs 147G 25G 123G 17% /data >> /dev/nvme0n1p2 ext3 283M 42M 227M 16% /boot >> /dev/nvme0n1p1 vfat 300M 724K 299M 1% /boot/efi >> tmpfs tmpfs 1.6G 160K 1.6G 1% /run/user/1001 >> /dev/sda1 ext4 1.8T 913G 827G 53% /home/loongson/test-file > > yaqsun has updated the pull request incrementally with one additional commit since the last revision: > > 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory @yaqsun Do need to use "/integrate" to integrate this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14436#issuecomment-1594103429 From duke at openjdk.org Fri Jun 16 06:19:08 2023 From: duke at openjdk.org (yaqsun) Date: Fri, 16 Jun 2023 06:19:08 GMT Subject: Integrated: 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 03:40:53 GMT, yaqsun wrote: > Low risk, only test changes. > java.nio.file.NoSuchFileException: ./name1692782213124882428/link when it is a different volume/file system. > machine info: > > ???? ?? ?? ?? ?? ??% ??? > devtmpfs devtmpfs 7.9G 0 7.9G 0% /dev > tmpfs tmpfs 7.9G 245M 7.7G 4% /dev/shm > tmpfs tmpfs 7.9G 893M 7.1G 12% /run > tmpfs tmpfs 5.0M 16K 5.0M 1% /run/lock > tmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup > /dev/nvme0n1p3 xfs 42G 24G 18G 58% / > /dev/nvme0n1p5 xfs 147G 25G 123G 17% /data > /dev/nvme0n1p2 ext3 283M 42M 227M 16% /boot > /dev/nvme0n1p1 vfat 300M 724K 299M 1% /boot/efi > tmpfs tmpfs 1.6G 160K 1.6G 1% /run/user/1001 > /dev/sda1 ext4 1.8T 913G 827G 53% /home/loongson/test-file This pull request has now been integrated. Changeset: cfae6ef2 Author: sunyaqi Committer: Jie Fu URL: https://git.openjdk.org/jdk/commit/cfae6ef2f61f0a6611de2f66e6e773c547ba7878 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8309778: java/nio/file/Files/CopyAndMove.java fails when using second test directory Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/14436 From alanb at openjdk.org Fri Jun 16 07:48:13 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jun 2023 07:48:13 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 15:05:19 GMT, Michael McMahon wrote: >> Hi, >> >> Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. >> >> The equivalent behavior has already been implemented for IPv4 sockets. >> >> Thanks, >> Michael. > > Michael McMahon has updated the pull request incrementally with two additional commits since the last revision: > > - typo > - review update Can you look at test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java? I wonder if this should be updated to exercise the test with two IPv6 multicast groups? In passing, I assume the check for the OS version isn't needed in this test anymore. As regards the new test then I think the naming should be a bit more consistent with the existing tests if possible. The existing test for IP_MULTICAST_ALL is Promiscuous so maybe the new test is PromiscuousIPv6 or something with "IPv6" in the name? The test launches "uname -r", maybe it can use the Platform test infra class instead. The class initializer probes for interfaces that support IPv6 multicasting. Can this be moved to the main method so that it's easier to see in main why the test is skipping? If < 4.20 then I think the test should just skip on Linux. No need to create a socket + close it. If we have an issue here then all DatagramChannel tests would fail. The select(2000) might not be enough on slow machines. So if we are keeping this test then I think it will need a few rounds of cleanup to make it more robust. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14491#issuecomment-1594258465 From michaelm at openjdk.org Fri Jun 16 08:16:05 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 16 Jun 2023 08:16:05 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 16:13:23 GMT, Alan Bateman wrote: >> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision: >> >> - typo >> - review update > > src/java.base/unix/native/libnio/ch/Net.c line 325: > >> 323: close(fd); >> 324: return -1; >> 325: } > > This implementation change looks okay, assuming ENOPROTOOPT on older kernels. I haven't had time to study the test yet, tricky scenario to test reliably. I am running some repeat 50 test runs of the datagram tests on the newer Linux systems. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1231933574 From michaelm at openjdk.org Fri Jun 16 08:28:01 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 16 Jun 2023 08:28:01 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 07:44:50 GMT, Alan Bateman wrote: > Can you look at test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java? I wonder if this should be updated to exercise the test with two IPv6 multicast groups? In passing, I assume the check for the OS version isn't needed in this test anymore. > Okay > As regards the new test then I think the naming should be a bit more consistent with the existing tests if possible. The existing test for IP_MULTICAST_ALL is Promiscuous so maybe the new test is PromiscuousIPv6 or something with "IPv6" in the name? > Right > The test launches "uname -r", maybe it can use the Platform test infra class instead. > Ah, I missed that Platform can return the os version numbers. Will change that. > The class initializer probes for interfaces that support IPv6 multicasting. Can this be moved to the main method so that it's easier to see in main why the test is skipping? > ok > If < 4.20 then I think the test should just skip on Linux. No need to create a socket + close it. If we have an issue here then all DatagramChannel tests would fail. > ok, I just added that after the previous round. I will take it out. > The select(2000) might not be enough on slow machines. So if we are keeping this test then I think it will need a few rounds of cleanup to make it more robust. I'll increase that. I suspect the test doesn't need othervm mode for that matter. Will change that too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14491#issuecomment-1594307582 From michaelm at openjdk.org Fri Jun 16 16:08:08 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 16 Jun 2023 16:08:08 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v3] In-Reply-To: References: Message-ID: > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. Michael McMahon has updated the pull request incrementally with two additional commits since the last revision: - removed new test and added to existing Promiscuous test - test update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14491/files - new: https://git.openjdk.org/jdk/pull/14491/files/37b4e8c9..e285b7d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=01-02 Stats: 220 lines in 3 files changed: 13 ins; 194 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/14491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14491/head:pull/14491 PR: https://git.openjdk.org/jdk/pull/14491 From michaelm at openjdk.org Fri Jun 16 16:08:11 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 16 Jun 2023 16:08:11 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 15:05:19 GMT, Michael McMahon wrote: >> Hi, >> >> Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. >> >> The equivalent behavior has already been implemented for IPv4 sockets. >> >> Thanks, >> Michael. > > Michael McMahon has updated the pull request incrementally with two additional commits since the last revision: > > - typo > - review update So, it turns out there is already an IPv6 version of the Promiscuous test. It only required a small change to this test to verify the behavior with the wildcard address. I updated it, and removed the new test. Updated both Promiscuous.java and PromiscuousIPv6.java to use the test library Platform utility. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14491#issuecomment-1594917439 From michaelm at openjdk.org Fri Jun 16 16:40:06 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 16 Jun 2023 16:40:06 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v4] In-Reply-To: References: Message-ID: > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: test update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14491/files - new: https://git.openjdk.org/jdk/pull/14491/files/e285b7d6..24ffab52 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14491/head:pull/14491 PR: https://git.openjdk.org/jdk/pull/14491 From alanb at openjdk.org Fri Jun 16 16:40:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jun 2023 16:40:07 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 16:03:46 GMT, Michael McMahon wrote: > So, it turns out there is already an IPv6 version of the Promiscuous test. It only required a small change to this test to verify the behavior with the wildcard address. I updated it, and removed the new test Good! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14491#issuecomment-1594957888 From alanb at openjdk.org Fri Jun 16 16:40:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jun 2023 16:40:09 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v4] In-Reply-To: References: Message-ID: <9heC8cG6_IZ_-FnLhvu7umoWUm4VYbeBxAEQU8QNk48=.309cfc2e-6312-4fda-ba0e-0cd7689c5fb6@github.com> On Fri, 16 Jun 2023 16:35:14 GMT, Michael McMahon wrote: >> Hi, >> >> Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. >> >> The equivalent behavior has already been implemented for IPv4 sockets. >> >> Thanks, >> Michael. > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > test update test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java line 212: > 210: } > 211: } > 212: Version check removed, good! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1232481065 From alanb at openjdk.org Fri Jun 16 16:40:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jun 2023 16:40:15 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 16:08:08 GMT, Michael McMahon wrote: >> Hi, >> >> Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. >> >> The equivalent behavior has already been implemented for IPv4 sockets. >> >> Thanks, >> Michael. > > Michael McMahon has updated the pull request incrementally with two additional commits since the last revision: > > - removed new test and added to existing Promiscuous test > - test update test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java line 212: > 210: > 211: // Linux allows IPv6 sockets join IPv4 multicast groups > 212: if (Platform.isLinux()) If you can, it would be useful to double check it is Linux specific, I would expect it should pass on Windows and macOS too. test/jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java line 150: > 148: static void test(ProtocolFamily family, > 149: NetworkInterface nif, > 150: boolean bindToWildCard, Wildcard rather than WildCard :-) test/jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java line 210: > 208: > 209: if (!Platform.isLinux()) { > 210: throw new SkippedException("This test should be run only on Linux"); The test has `@requires os.family == "linux" so it only runs on Linux. It doesn't need both, and maybe it will pass on Windows too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1232482223 PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1232485030 PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1232483517 From duke at openjdk.org Fri Jun 16 17:19:28 2023 From: duke at openjdk.org (Terry Chow) Date: Fri, 16 Jun 2023 17:19:28 GMT Subject: RFR: 8308593: Add Keepalive Extended Socket Options Support for Windows [v2] In-Reply-To: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com> References: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com> Message-ID: > The PR adds support for the keepalive extended socket options on Windows. For TCP_KEEPIDLE and TCP_KEEPINTVL, these options are supported starting from Windows 10 version 1709. TCP_KEEPCNT is supported starting from Windows 10 version 1703. Information on these socket options can be found [here](https://learn.microsoft.com/en-us/windows/win32/winsock/ipproto-tcp-socket-options). > > I've also corrected the `handleError()` function. On Windows, the error needs to be retrieved using `WSAGetLastError()` and error codes are prefixed with "WSA". Information on this can be found [here](https://learn.microsoft.com/en-us/windows/win32/winsock/error-codes-errno-h-errno-and-wsagetlasterror-2). > >>The error codes returned by Windows Sockets are similar to UNIX socket error code constants, but the constants are all prefixed with WSA. > >>Error codes set by Windows Sockets are not made available through the errno variable. > > No new tests were added as the existing tests should cover this. Terry Chow 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 one additional commit since the last revision: Support keepalive extended socket options for Windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14232/files - new: https://git.openjdk.org/jdk/pull/14232/files/a7858982..2ada2207 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14232&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14232&range=00-01 Stats: 78650 lines in 1390 files changed: 57268 ins; 16375 del; 5007 mod Patch: https://git.openjdk.org/jdk/pull/14232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14232/head:pull/14232 PR: https://git.openjdk.org/jdk/pull/14232 From naoto at openjdk.org Fri Jun 16 17:41:03 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 Jun 2023 17:41:03 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v4] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 23:09:24 GMT, Justin Lu wrote: >> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. > > Justin Lu has updated the pull request incrementally with three additional commits since the last revision: > > - Review: Move default test back to RegisteredCharsets.java > - Review: rename standard charsets test > - Revert "Remove Default test" > > This reverts commit 346cb4c050adb8bd8a3cb942e25a98484703b997. test/jdk/java/nio/charset/Charset/IllegalCharsetName.java line 50: > 48: assertThrows(IllegalArgumentException.class, > 49: () -> Charset.forName(null)); > 50: } Missed this one previously. This one is also not `IllegalCharsetName`, so I'd prefer not to merge this either. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1232543764 From jlu at openjdk.org Fri Jun 16 18:23:40 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 16 Jun 2023 18:23:40 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v4] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 17:36:16 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with three additional commits since the last revision: >> >> - Review: Move default test back to RegisteredCharsets.java >> - Review: rename standard charsets test >> - Revert "Remove Default test" >> >> This reverts commit 346cb4c050adb8bd8a3cb942e25a98484703b997. > > test/jdk/java/nio/charset/Charset/IllegalCharsetName.java line 50: > >> 48: assertThrows(IllegalArgumentException.class, >> 49: () -> Charset.forName(null)); >> 50: } > > Missed this one previously. This one is also not `IllegalCharsetName`, so I'd prefer not to merge this either. I guess when I think of illegal (I group anything that is _wrong_, so I initially included null and "default"). But you are right that it does not throw IllegalCharsetNameException so it should be moved into its own test. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1232588591 From jlu at openjdk.org Fri Jun 16 18:23:40 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 16 Jun 2023 18:23:40 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v5] In-Reply-To: References: Message-ID: > As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Review: Make null charset its own test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14500/files - new: https://git.openjdk.org/jdk/pull/14500/files/6a39ceab..bc50c6f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14500&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14500&range=03-04 Stats: 52 lines in 2 files changed: 44 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14500.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14500/head:pull/14500 PR: https://git.openjdk.org/jdk/pull/14500 From naoto at openjdk.org Fri Jun 16 18:35:10 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 Jun 2023 18:35:10 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v5] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 18:23:40 GMT, Justin Lu wrote: >> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Review: Make null charset its own test Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14500#pullrequestreview-1484108191 From lancea at openjdk.org Fri Jun 16 19:29:21 2023 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 16 Jun 2023 19:29:21 GMT Subject: RFR: 8310049: Refactor Charset tests to use JUnit [v5] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 18:23:40 GMT, Justin Lu wrote: >> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Review: Make null charset its own test Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14500#pullrequestreview-1484203706 From bpb at openjdk.org Sat Jun 17 02:17:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Sat, 17 Jun 2023 02:17:25 GMT Subject: RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3] In-Reply-To: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> References: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> Message-ID: On Sun, 9 Apr 2023 13:43:36 GMT, Markus KARG wrote: >> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of ReadableByteChannel-to-WritableByteChannel transfers, where neither Channel is a FileChannel, but including special treatment of SelectableByteChannel. >> >> *Without* this optimization, the JRE applies a loop where a temporary 16k byte array on the Java heap is used to transport the data between both channels. This implies that data is first transported from the source channel into the Java heap and then from the Java heap to the target channel. For most Channels, as these are NIO citizen, this implies two transfers between Java heap and OS resources, which is rather time consuming. As the data is in no way modified by transferTo(), the temporary allocation of valuable heap memory is just as unnecessary as both transfers to and from the heap. It makes sense to prevent the use of Java heap memory. >> >> This optimization omits the byte array on the Java heap, effectively omitting the transfers to and from that array in turn. Instead, the transfer happens directly from Channel to Channel reusing a ByteBuffer taken from the JRE's internal buffer management utility which also has a size of 16k. Both measures make the transfer more efficient, as just the very essential resources are used, but not more. >> >> Using JMH on an in-memory data transfer using custom Channels (to prevent interception by other optimizations already existing in transferTo()) it was possible to measure a 2,5% performance gain. While this does not sound much, just as the spared 16k of Java heap doesn't, we need to consider that this also means sparing GC pressure, power consumption and CO2 footprint, and we need to consider that it could be higher when using different (possibly third-party) kinds of custom Channels (as "real I/O" between heap and OS-resources is way slower than the RAM-to-RAM benchmark applied by me). As the change does not induce new, extraordinary risks compared to the existing source code, I think it is worth gaining that 2,5+ percent. Possibly there might exist some kind of scalable Java-implemented cloud service that is bound to exactly this loop and that transports very heavy traffic, those particular 2,5+ percent could be a huge amount of kWh or CO2 in absolute numbers. Even if not now, t here might be in future. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Putting the special casing for an output stream backed by a ChannelOutputStream in one place. > ```java > @Benchmark > public void ChannelInputStream_transferTo() throws Throwable { > var is = Channels.newInputStream(Channels.newChannel(new ByteArrayInputStream(new byte[1024 * 1024 * 1024]))); > var os = Channels.newOutputStream(Channels.newChannel(new ByteArrayOutputStream(1024 * 1024 * 1024))); > is.transferTo(os); > } > ``` The above benchmark method includes the construction of 6 objects in the measurement. I think it would be more representative of the effect of the change to do something like this: private static final int SIZE = 1024*1024*1024; ByteArrayInputStream in = new ByteArrayInputStream(new byte[SIZE]); ByteArrayOutputStream out = new ByteArrayOutputStream(SIZE); ReadableByteChannel rbc = Channels.newChannel(in); WritableByteChannel wbc = Channels.newChannel(out); InputStream is = Channels.newInputStream(rbc); OutputStream os = Channels.newOutputStream(wbc); @Setup public void setup() { in.mark(SIZE + 1); } @Benchmark public void ChannelInputStream_transferTo() throws Throwable { is.transferTo(os); in.reset(); out.reset(); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/13387#issuecomment-1595580843 From duke at openjdk.org Sat Jun 17 11:41:08 2023 From: duke at openjdk.org (Markus KARG) Date: Sat, 17 Jun 2023 11:41:08 GMT Subject: RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3] In-Reply-To: References: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> Message-ID: On Sat, 17 Jun 2023 02:14:17 GMT, Brian Burkhalter wrote: > The above benchmark method includes the construction of 6 objects in the measurement. I think it would be more representative of the effect of the change to do something like this: Correct, the benchmark could be tweaked to proof better results, but as I said in my original posting of that code: "I measured the code that might benefit *the least* from the optimization", as my claim was: It does *never* do harm, so *why not* doing it. :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13387#issuecomment-1595719668 From michaelm at openjdk.org Mon Jun 19 15:26:24 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 19 Jun 2023 15:26:24 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v4] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 16:40:06 GMT, Michael McMahon wrote: >> Hi, >> >> Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. >> >> The equivalent behavior has already been implemented for IPv4 sockets. >> >> Thanks, >> Michael. > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > test update So, the test Promiscuous.java (the IPv4 version) can run on all platforms now. The IPv6 version (PromiscuousIPv6.java) still does not work on Windows. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14491#issuecomment-1597374568 From michaelm at openjdk.org Mon Jun 19 15:26:23 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 19 Jun 2023 15:26:23 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v5] In-Reply-To: References: Message-ID: <6_XpMB_lHzyJx6lPZR5CGZMj0zh1QjaFEyiRjSoVyxo=.b0f4c7f7-5e06-4078-9b51-4a0b8ca5e9b5@github.com> > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: Test updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14491/files - new: https://git.openjdk.org/jdk/pull/14491/files/24ffab52..14ea193c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=03-04 Stats: 10 lines in 2 files changed: 0 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14491/head:pull/14491 PR: https://git.openjdk.org/jdk/pull/14491 From michaelm at openjdk.org Mon Jun 19 15:30:02 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 19 Jun 2023 15:30:02 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v6] In-Reply-To: References: Message-ID: <7OEWGc2UFbkzkAahpUDXWAXWoLr0WQgAshJOp99ENd0=.ac5e557e-9a3b-4592-a3f4-60492a7c2769@github.com> > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. Michael McMahon 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 13 additional commits since the last revision: - Merge branch 'master' into ipv6opt - Test updates - test update - removed new test and added to existing Promiscuous test - test update - typo - review update - added test comment - Merge branch 'master' into ipv6opt - test fix - ... and 3 more: https://git.openjdk.org/jdk/compare/03514d1e...bd7ff0b6 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14491/files - new: https://git.openjdk.org/jdk/pull/14491/files/14ea193c..bd7ff0b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=04-05 Stats: 6468 lines in 269 files changed: 4258 ins; 1191 del; 1019 mod Patch: https://git.openjdk.org/jdk/pull/14491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14491/head:pull/14491 PR: https://git.openjdk.org/jdk/pull/14491 From michaelm at openjdk.org Mon Jun 19 15:37:54 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 19 Jun 2023 15:37:54 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v7] In-Reply-To: References: Message-ID: > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14491/files - new: https://git.openjdk.org/jdk/pull/14491/files/bd7ff0b6..ed0243ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14491/head:pull/14491 PR: https://git.openjdk.org/jdk/pull/14491 From alanb at openjdk.org Mon Jun 19 15:41:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 Jun 2023 15:41:07 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v7] In-Reply-To: References: Message-ID: On Mon, 19 Jun 2023 15:37:54 GMT, Michael McMahon wrote: >> Hi, >> >> Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. >> >> The equivalent behavior has already been implemented for IPv4 sockets. >> >> Thanks, >> Michael. > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > whitespace test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java line 46: > 44: > 45: import jdk.test.lib.NetworkConfiguration; > 46: import jdk.test.lib.Platform; I assume this isn't needed for the current patch. test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java line 212: > 210: > 211: // test IPv6 sockets joining IPv4 multicast groups > 212: test(UNSPEC, nif, ip4Group1, ip4Group2); The SAP and/or IBM folks that maintain the AIX port will probably have to adjust this to skip on that platform. test/jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java line 213: > 211: int major = Platform.getOsVersionMajor(); > 212: int minor = Platform.getOsVersionMinor(); > 213: hasIPV6MulticastAll = Platform.isOSX() || (major > 4) || ((major == 4 && minor >= 20)); The version check should be Linux only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1234219653 PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1234220343 PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1234221155 From michaelm at openjdk.org Mon Jun 19 16:01:59 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 19 Jun 2023 16:01:59 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v8] In-Reply-To: References: Message-ID: > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: missing parentheses ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14491/files - new: https://git.openjdk.org/jdk/pull/14491/files/ed0243ba..b54baa04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=06-07 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14491/head:pull/14491 PR: https://git.openjdk.org/jdk/pull/14491 From michaelm at openjdk.org Mon Jun 19 16:02:03 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 19 Jun 2023 16:02:03 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v7] In-Reply-To: References: Message-ID: On Mon, 19 Jun 2023 15:37:13 GMT, Alan Bateman wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> whitespace > > test/jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java line 213: > >> 211: int major = Platform.getOsVersionMajor(); >> 212: int minor = Platform.getOsVersionMinor(); >> 213: hasIPV6MulticastAll = Platform.isOSX() || (major > 4) || ((major == 4 && minor >= 20)); > > The version check should be Linux only. It runs the additional tests if it is MacOSX or if Linux and kernel > 4.20. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1234234346 From alanb at openjdk.org Mon Jun 19 16:02:04 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 Jun 2023 16:02:04 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v7] In-Reply-To: References: Message-ID: On Mon, 19 Jun 2023 15:50:58 GMT, Michael McMahon wrote: >> test/jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java line 213: >> >>> 211: int major = Platform.getOsVersionMajor(); >>> 212: int minor = Platform.getOsVersionMinor(); >>> 213: hasIPV6MulticastAll = Platform.isOSX() || (major > 4) || ((major == 4 && minor >= 20)); >> >> The version check should be Linux only. > > It runs the additional tests if it is MacOSX or if Linux and kernel > 4.20. It looks like it's good the version check on AIX too. I think you'll need to include a check for isLinux to avoid a follow-up bug from the maintainers of that port. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1234236935 From michaelm at openjdk.org Mon Jun 19 16:02:05 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 19 Jun 2023 16:02:05 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v7] In-Reply-To: References: Message-ID: On Mon, 19 Jun 2023 15:53:55 GMT, Alan Bateman wrote: >> It runs the additional tests if it is MacOSX or if Linux and kernel > 4.20. > > It looks like it's good the version check on AIX too. I think you'll need to include a check for isLinux to avoid a follow-up bug from the maintainers of that port. Oh, I see there is a missing pair of parentheses. I will fix that ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1234237370 From michaelm at openjdk.org Mon Jun 19 16:35:14 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 19 Jun 2023 16:35:14 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v7] In-Reply-To: References: Message-ID: On Mon, 19 Jun 2023 15:54:23 GMT, Michael McMahon wrote: >> It looks like it's good the version check on AIX too. I think you'll need to include a check for isLinux to avoid a follow-up bug from the maintainers of that port. > > Oh, I see there is a missing pair of parentheses. I will fix that Ok then. I'll add explicit tests for Linux, Mac and Windows (for the IPv4 test), and Linux + Mac for the IPv6 one. The AIX folks can add that if/when they verify it works. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1234266323 From michaelm at openjdk.org Mon Jun 19 16:48:28 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 19 Jun 2023 16:48:28 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v9] In-Reply-To: References: Message-ID: > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: added explicit platform checks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14491/files - new: https://git.openjdk.org/jdk/pull/14491/files/b54baa04..3e900f1e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=07-08 Stats: 17 lines in 2 files changed: 13 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14491/head:pull/14491 PR: https://git.openjdk.org/jdk/pull/14491 From alanb at openjdk.org Mon Jun 19 17:11:12 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 Jun 2023 17:11:12 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v9] In-Reply-To: References: Message-ID: On Mon, 19 Jun 2023 16:48:28 GMT, Michael McMahon wrote: >> Hi, >> >> Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. >> >> The equivalent behavior has already been implemented for IPv4 sockets. >> >> Thanks, >> Michael. > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > added explicit platform checks Marked as reviewed by alanb (Reviewer). test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java line 196: > 194: } > 195: > 196: private static boolean supportedByPlatform() { Do you mind adding a /**/ comment to this method to say that it returns true if platform allows an IPv6 socket join an IPv4 multicast group? test/jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java line 204: > 202: } > 203: > 204: private static boolean supportedByPlatform() { This method too, I think it needs a comment to this method to say that it returns true if platform allows an IPv6 socket join an IPv4 multicast group without interference. ------------- PR Review: https://git.openjdk.org/jdk/pull/14491#pullrequestreview-1486592930 PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1234290608 PR Review Comment: https://git.openjdk.org/jdk/pull/14491#discussion_r1234291006 From michaelm at openjdk.org Mon Jun 19 21:40:18 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 19 Jun 2023 21:40:18 GMT Subject: Integrated: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 10:47:58 GMT, Michael McMahon wrote: > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. This pull request has now been integrated. Changeset: 7b45c8fc Author: Michael McMahon URL: https://git.openjdk.org/jdk/commit/7b45c8fc3a0d8b7f7de196fe095d2fa47c6bd60a Stats: 78 lines in 3 files changed: 43 ins; 18 del; 17 mod 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/14491 From michaelm at openjdk.org Mon Jun 19 21:40:16 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 19 Jun 2023 21:40:16 GMT Subject: RFR: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups [v10] In-Reply-To: References: Message-ID: > Hi, > > Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system. > > The equivalent behavior has already been implemented for IPv4 sockets. > > Thanks, > Michael. Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: added comment to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14491/files - new: https://git.openjdk.org/jdk/pull/14491/files/3e900f1e..7dfb9e79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14491&range=08-09 Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14491/head:pull/14491 PR: https://git.openjdk.org/jdk/pull/14491 From bpb at openjdk.org Tue Jun 20 16:21:34 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 20 Jun 2023 16:21:34 GMT Subject: RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3] In-Reply-To: References: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> Message-ID: <4rdX4cbGBmIHLwAYVrktXqqbHfaDVcyZOl20mJcCYrM=.f0f2d978-9e73-4304-87e3-36ba5db4a9af@github.com> On Sat, 17 Jun 2023 11:38:46 GMT, Markus KARG wrote: > Correct, the benchmark could be tweaked to proof better results It would be better if the benchmark were so updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13387#issuecomment-1599109844 From jlu at openjdk.org Tue Jun 20 17:24:22 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 20 Jun 2023 17:24:22 GMT Subject: Integrated: 8310049: Refactor Charset tests to use JUnit In-Reply-To: References: Message-ID: <69tck2mSw8WVRxfMiPDhjXxwJKk6gEINqBC-d4Xogz4=.50adc537-44dc-41fa-84bd-506ee0c4a637@github.com> On Thu, 15 Jun 2023 19:42:56 GMT, Justin Lu wrote: > As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. This pull request has now been integrated. Changeset: 09174e0c Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/09174e0c994dfb19fd09f551720c13c6479812d4 Stats: 2072 lines in 8 files changed: 425 ins; 376 del; 1271 mod 8310049: Refactor Charset tests to use JUnit Reviewed-by: lancea, naoto ------------- PR: https://git.openjdk.org/jdk/pull/14500 From alanb at openjdk.org Tue Jun 20 17:52:04 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 Jun 2023 17:52:04 GMT Subject: RFR: 8310426: (ch) Channels.newInputStream transferTo cleanup Message-ID: ChannelInputStream, the InputStream returned by Channels.newInputStream, implements the transferTo method with support for the cross product of many interesting underlying channels. It's getting a bit too unwieldy and can be simplified by introducing a FileChannelInputStream to wrap a FileChannel. ------------- Commit messages: - Fix typo in comment - Update - Initial commit Changes: https://git.openjdk.org/jdk/pull/14566/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14566&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310426 Stats: 336 lines in 8 files changed: 232 ins; 43 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/14566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14566/head:pull/14566 PR: https://git.openjdk.org/jdk/pull/14566 From jlu at openjdk.org Tue Jun 20 18:05:20 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 20 Jun 2023 18:05:20 GMT Subject: RFR: 8310458: Fix build failure caused by JDK-8310049 Message-ID: Please review this PR which fixes the build failure caused by JDK-8310049 by adding a "," after the 2023. ------------- Commit messages: - Fix copyright header, missing ',' Changes: https://git.openjdk.org/jdk/pull/14568/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14568&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310458 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14568/head:pull/14568 PR: https://git.openjdk.org/jdk/pull/14568 From rriggs at openjdk.org Tue Jun 20 18:05:21 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 20 Jun 2023 18:05:21 GMT Subject: RFR: 8310458: Fix build failure caused by JDK-8310049 In-Reply-To: References: Message-ID: <6W1qVJ_FYxukjU07yoYJUX_d3KdfG1w7E8CY5Q1x01Y=.8708b9a2-d3e4-4b20-a13c-670579337bee@github.com> On Tue, 20 Jun 2023 17:58:39 GMT, Justin Lu wrote: > Please review this PR which fixes the build failure caused by JDK-8310049 by adding a "," after the 2023. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14568#pullrequestreview-1488711580 From naoto at openjdk.org Tue Jun 20 18:14:02 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 20 Jun 2023 18:14:02 GMT Subject: RFR: 8310458: Fix build failure caused by JDK-8310049 In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 17:58:39 GMT, Justin Lu wrote: > Please review this PR which fixes the build failure caused by JDK-8310049 by adding a "," after the 2023. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14568#pullrequestreview-1488733911 From jlu at openjdk.org Tue Jun 20 18:19:11 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 20 Jun 2023 18:19:11 GMT Subject: Integrated: 8310458: Fix build failure caused by JDK-8310049 In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 17:58:39 GMT, Justin Lu wrote: > Please review this PR which fixes the build failure caused by JDK-8310049 by adding a "," after the 2023. This pull request has now been integrated. Changeset: 11201067 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/11201067a8d429fcb03f90830abec1842efae5fd Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8310458: Fix build failure caused by JDK-8310049 Reviewed-by: rriggs, naoto ------------- PR: https://git.openjdk.org/jdk/pull/14568 From bpb at openjdk.org Tue Jun 20 18:38:03 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 20 Jun 2023 18:38:03 GMT Subject: RFR: 8310426: (ch) Channels.newInputStream transferTo cleanup In-Reply-To: References: Message-ID: <99CAR_Sk86aBH2frB8Q80LtU2zFhjnNJOvsnlc2Owb4=.8482e13d-cc97-4bec-9155-a70ed12cb8fb@github.com> On Tue, 20 Jun 2023 15:15:51 GMT, Alan Bateman wrote: > ChannelInputStream, the InputStream returned by Channels.newInputStream, implements the transferTo method with support for the cross product of many interesting underlying channels. It's getting a bit too unwieldy and can be simplified by introducing a FileChannelInputStream to wrap a FileChannel. test/jdk/java/nio/channels/Channels/TransferTo.java line 52: > 50: * @build jdk.test.lib.RandomFactory > 51: * @run testng/othervm/timeout=180 TransferTo > 52: * @bug 8265891 Add 8310426? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14566#discussion_r1235664534 From duke at openjdk.org Tue Jun 20 21:48:02 2023 From: duke at openjdk.org (Markus KARG) Date: Tue, 20 Jun 2023 21:48:02 GMT Subject: RFR: 8310426: (ch) Channels.newInputStream transferTo cleanup In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 15:15:51 GMT, Alan Bateman wrote: > ChannelInputStream, the InputStream returned by Channels.newInputStream, implements the transferTo method with support for the cross product of many interesting underlying channels. It's getting a bit too unwieldy and can be simplified by introducing a FileChannelInputStream to wrap a FileChannel. The undoubted benefits (pros) of this PR is: * A cleaner ChannelInputStream::transferTo implementation. The obvious drawbacks (contras) of this PR are: * The overall optimization solution ("the sum of all optimizations") is much harder to grasp now (it took me half an hour just to check if we still cover the full cross product), as the solution is scattered over lots of files now. In contrast, a central place was much simpler to grasp before this PR. * IIUC the PR needed to duplicate algorithms just for the sole sake of code cleanup. In contrast, a central place was the sole source of truth for all transfer algorithms before this PR. * The new solution is much more complex and comes with additional classes just for the sole sake of a method's cleanup; those classes apparently have no other benefit, at least so far. IMHO the single benefit does not outweigh the multiple drawbacks. A counter proposal for a compromise between this PR (code duplication) and the original code (single source of truth) could be: * Let's refactor the cross product (the original trigger for this PR) on the channel level (not on the stream level) into a new static utility method Channels::transfer(ReadableByteChannel, WritableByteChannel), and let's call that single method from all code locations where "some channels" need to transfer bytes. The benefit of the counter proposal would be: * Keeping a single source of truth, which does not need code duplication, and which is easy to grasp (all optimization rules in one place). * Can be used with either the original code and/or the new PR. * Can simply get centrally extended in case a future OS comes up with a new type of optimization API eventually, e. g. hardware-implemented Socket-to-Socket transfers. * Could even get used by other JDK locations, and/or custom application code that wants to perform optimized non-stream channel-to-channel transfers. ------------- PR Review: https://git.openjdk.org/jdk/pull/14566#pullrequestreview-1489148545 From duke at openjdk.org Tue Jun 20 21:55:05 2023 From: duke at openjdk.org (Markus KARG) Date: Tue, 20 Jun 2023 21:55:05 GMT Subject: RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3] In-Reply-To: <4rdX4cbGBmIHLwAYVrktXqqbHfaDVcyZOl20mJcCYrM=.f0f2d978-9e73-4304-87e3-36ba5db4a9af@github.com> References: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> <4rdX4cbGBmIHLwAYVrktXqqbHfaDVcyZOl20mJcCYrM=.f0f2d978-9e73-4304-87e3-36ba5db4a9af@github.com> Message-ID: On Tue, 20 Jun 2023 16:18:32 GMT, Brian Burkhalter wrote: > It would be better if the benchmark were so updated. I will change the benchmark as you proposed and run it again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13387#issuecomment-1599612662 From bpb at openjdk.org Tue Jun 20 21:59:07 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 20 Jun 2023 21:59:07 GMT Subject: RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3] In-Reply-To: References: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> <4rdX4cbGBmIHLwAYVrktXqqbHfaDVcyZOl20mJcCYrM=.f0f2d978-9e73-4304-87e3-36ba5db4a9af@github.com> Message-ID: On Tue, 20 Jun 2023 21:52:03 GMT, Markus KARG wrote: > I will change the benchmark as you proposed and run it again. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13387#issuecomment-1599622715 From bpb at openjdk.org Tue Jun 20 22:18:03 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 20 Jun 2023 22:18:03 GMT Subject: RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3] In-Reply-To: References: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> Message-ID: On Sat, 17 Jun 2023 02:14:17 GMT, Brian Burkhalter wrote: > @Setup > public void setup() { > in.mark(SIZE + 1); > } In my benchmark example the above code is unneeded. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13387#issuecomment-1599644390 From alanb at openjdk.org Wed Jun 21 10:59:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jun 2023 10:59:05 GMT Subject: RFR: 8310426: (ch) Channels.newInputStream transferTo cleanup In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 21:45:33 GMT, Markus KARG wrote: > IMHO the single benefit does not outweigh the multiple drawbacks. SocketInputStream is already tightly coupled to the underlying SocketChannelImpl, it's not a ChannelInputStream. More is required here to avoid needing the use the blockingLock, make SIS.transferTo friendly to virtual thread usages, and also to coordinate with async close of a target FileChannel. With FileInputStream, the idea is the same, it will be able to coordinate with FileChannelImpl internals. I think ChannelInputStream should be a simple input stream based on a readable channel. It can delegate to FileChannel.transferFrom when the target is an output stream that is based on a FileChannel but beyond that, I don't think we want it to have a close relationship with SocketChannelImpl or FileChannel internals. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14566#issuecomment-1600623745 From duke at openjdk.org Wed Jun 21 15:06:13 2023 From: duke at openjdk.org (Pushkar N Kulkarni) Date: Wed, 21 Jun 2023 15:06:13 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> Message-ID: On Tue, 13 Jun 2023 07:01:28 GMT, Alan Bateman wrote: >>> Well, in that area we always had deviations on AIX, so definitely this rings a bell. However, since AIX was not the most important platform for us and that particular IPv6/IPv4 multicast feature didn't seem to be mission critical and wouldn't fail TCK tests, we rather resorted to excluding some tests internally, I believe. But it would be good to really resolve this compatibility/spec/documentation issue, if possible. >> >> Thanks. So yes, if some/all of the tests for multicasting were excluded then it helps explain why it didn't come up. The spec doesn't require that a DatgaramSocket or DatagramChannel to an IPv6 socket be capable of joining an IPv4 multicast group. So the tests in several areas might need updates as I don't think we've had a platform to date where it wasn't possible. > >> @AlanBateman , is it possible if there is a central place where the change could me made for fixing all of the multicast test cases? > > Your starting point is probably to exclude all of the tests that are failing. This will be tests for DatagramSocket/MulticastSocket, DatagramChannel and the tests for the JMX agent that use the discovery protocol. Once they are excluded then you can start working through the issues. > > For the JMX agent, then I would expect that if if the system property com.sun.management.jdp.address is configured then the protocol family is known so it should be possible to create the DatagramChannel to use that protocol family. It might do so already, but you can check that. > > For the networking and NIO tests then you probably should look at jdk.test.lib.NetworkConfiguration. That has a number of AIX specific comments that may be out of date. After that I think you will need to work through the tests one by one. Between NetworkConfiguration and jdk.test.lib.net.IPSupport, I would expect you have all the infrastructure needed for the tests to not attempt to join IPv4 multicast groups when IPSupport.hasIPv6() is true. > > Yes, I agree with @AlanBateman and @msheppar . Even when we try to have an IPv4 multicast socket join an IPv4 multicast group, we still fail because the delegate that is created for an IPv4 multicast socket is IPv4/IPv6 (dual stack) in nature. AIX does not allow dual stack (IPv4/IPv6) sockets to join IPv4 multicast groups. > > The "Platform dependencies" section in the java.nio.channels.MulticastChannel (implemented by DatagramChannel) makes it clear that it is implementation specific as to whether a channel to an IPv6 socket can join an IPv4 multicast group. The recommendation is to specify the protocol family when creating the channel. Legacy DatagramSocket/MulticastSocket do not define a constructor that allows the protocol family be specified at xxxSocket create time. That issue has been there since JDK 1.4 when IPv6 support was added. I'm curious why this might be coming up with AIX now. IIUC what @deepa181 is saying, it looks like the "IPv4 socket being unable to join an IPv4 multicast group" problems surfaced when we moved away from `PlainDatagramSocketImpl` in JDK 17? Probably because the `delegate` created does not factor in the `ProtocolFamily` and though we started with attempting to have an "IPv4 multicast socket join an IPv4 group", we end up trying to have an "IPv4/IPv6 dual-stack socket (the delegate) join an IPv4 group" which AIX doesn't permit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1601007522 From dfuchs at openjdk.org Wed Jun 21 15:23:10 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 21 Jun 2023 15:23:10 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: <5ai8MHV2EQmFEcuMNWYM7Rz88cUl9dVnXNQolLQ3Jp8=.af5976df-6b30-4842-9b5a-7550e2fcdd0a@github.com> References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> <5ai8MHV2EQmFEcuMNWYM7Rz88cUl9dVnXNQolLQ3Jp8=.af5976df-6b30-4842-9b5a-7550e2fcdd0a@github.com> Message-ID: On Mon, 12 Jun 2023 19:27:28 GMT, Deepa Kumari wrote: >>> Well, in that area we always had deviations on AIX, so definitely this rings a bell. However, since AIX was not the most important platform for us and that particular IPv6/IPv4 multicast feature didn't seem to be mission critical and wouldn't fail TCK tests, we rather resorted to excluding some tests internally, I believe. But it would be good to really resolve this compatibility/spec/documentation issue, if possible. >> >> Thanks. So yes, if some/all of the tests for multicasting were excluded then it helps explain why it didn't come up. The spec doesn't require that a DatgaramSocket or DatagramChannel to an IPv6 socket be capable of joining an IPv4 multicast group. So the tests in several areas might need updates as I don't think we've had a platform to date where it wasn't possible. > >> > Well, in that area we always had deviations on AIX, so definitely this rings a bell. However, since AIX was not the most important platform for us and that particular IPv6/IPv4 multicast feature didn't seem to be mission critical and wouldn't fail TCK tests, we rather resorted to excluding some tests internally, I believe. But it would be good to really resolve this compatibility/spec/documentation issue, if possible. >> >> Thanks. So yes, if some/all of the tests for multicasting were excluded then it helps explain why it didn't come up. The spec doesn't require that a DatgaramSocket or DatagramChannel to an IPv6 socket be capable of joining an IPv4 multicast group. So the tests in several areas might need updates as I don't think we've had a platform to date where it wasn't possible. > > @AlanBateman , is it possible if there is a central place where the change could me made for fixing all of the multicast test cases? > IIUC what @deepa181 is saying, it looks like the "IPv4 socket being unable to join an IPv4 multicast group" problems surfaced when we moved away from PlainDatagramSocketImpl in JDK 17? Probably because the delegate created does not factor in the ProtocolFamily and though we started with attempting to have an "IPv4 multicast socket join an IPv4 group", we end up trying to have an "IPv4/IPv6 dual-stack socket (the delegate) join an IPv4 group" which AIX doesn't permit. IIRC It has never been possible to create a non-dual `MulticastSocket` / `DatagramSocket` without setting the property `-Djava.net.preferIPv4Stack=true`. The possibility to select a protocol family independently of this property is only available with `DatagramChannel`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1601038453 From alanb at openjdk.org Wed Jun 21 15:48:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jun 2023 15:48:09 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> <5ai8MHV2EQmFEcuMNWYM7Rz88cUl9dVnXNQolLQ3Jp8=.af5976df-6b30-4842-9b5a-7550e2fcdd0a@github.com> Message-ID: <-6rjVxKJKaCis7qu8jwSTxqsqXtGtrvpd4hY-JA3TZ0=.2a9ba8ab-8c14-48eb-a35d-3b3c150740f9@github.com> On Wed, 21 Jun 2023 15:18:32 GMT, Daniel Fuchs wrote: > IIRC It has never been possible to create a non-dual `MulticastSocket` / `DatagramSocket` without setting the property `-Djava.net.preferIPv4Stack=true`. The possibility to select a protocol family independently of this property is only available with `DatagramChannel`. Right now, Net.canIPv6SocketJoinIPv4Group() returns false on AIX so it will never attempt to join an IPv4 multicast group when the socket is IPv6. The old DatagamSocketImpl didn't have an eager check, which makes me wonder what AIX supports and doesn't support, it's not clear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1601085660 From naoto at openjdk.org Wed Jun 21 17:32:01 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 21 Jun 2023 17:32:01 GMT Subject: RFR: 8310047: Add UTF-32 based Charsets into StandardCharsets Message-ID: To make UTF-32 consistent with other UTF Charsets, making them available as `StandardCharsets`. A CSR has also been drafted. ------------- Commit messages: - 8310047: Add UTF-32 based Charsets into StandardCharsets Changes: https://git.openjdk.org/jdk/pull/14599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14599&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310047 Stats: 59 lines in 4 files changed: 49 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/14599.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14599/head:pull/14599 PR: https://git.openjdk.org/jdk/pull/14599 From alanb at openjdk.org Wed Jun 21 18:30:02 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jun 2023 18:30:02 GMT Subject: RFR: 8310047: Add UTF-32 based Charsets into StandardCharsets In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 17:24:19 GMT, Naoto Sato wrote: > To make UTF-32 consistent with other UTF Charsets, making them available as `StandardCharsets`. A CSR has also been drafted. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14599#pullrequestreview-1491435344 From duke at openjdk.org Wed Jun 21 18:58:04 2023 From: duke at openjdk.org (ExE Boss) Date: Wed, 21 Jun 2023 18:58:04 GMT Subject: RFR: 8310047: Add UTF-32 based Charsets into StandardCharsets In-Reply-To: References: Message-ID: <-68shLAlj83pnJaov6F18EL_EGejjvuLraqp0bPmXTk=.747ce208-4747-4d88-8e21-ca5628e3c135@github.com> On Wed, 21 Jun 2023 17:24:19 GMT, Naoto Sato wrote: > To make UTF-32 consistent with other UTF Charsets, making them available as `StandardCharsets`. A CSR has also been drafted. test/jdk/java/nio/charset/StandardCharsets/Standard.java line 45: > 43: "US-ASCII", "ISO-8859-1", "UTF-8", > 44: "UTF-16BE", "UTF-16LE", "UTF-16", > 45: "UTF-32BE", "UTF-32LE", "UTF-32" }; Maybe?add a?newline?after the?last?item? Suggestion: "UTF-32BE", "UTF-32LE", "UTF-32", }; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14599#discussion_r1237448986 From lancea at openjdk.org Wed Jun 21 19:04:05 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 21 Jun 2023 19:04:05 GMT Subject: RFR: 8310047: Add UTF-32 based Charsets into StandardCharsets In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 17:24:19 GMT, Naoto Sato wrote: > To make UTF-32 consistent with other UTF Charsets, making them available as `StandardCharsets`. A CSR has also been drafted. Looks good. Hopefully we can convert the tests to junit at some point as started with some of the other tests in this area(to be done under a separate PR of course :-) ) ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14599#pullrequestreview-1491523572 From naoto at openjdk.org Wed Jun 21 19:40:07 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 21 Jun 2023 19:40:07 GMT Subject: RFR: 8310047: Add UTF-32 based Charsets into StandardCharsets [v2] In-Reply-To: References: Message-ID: <8-UxoxUg0sh7nGQKDWWqDWdWdvmkom3xmKK36f2UlN0=.e4979e04-4ae5-4a2c-8f28-ff2811a49067@github.com> > To make UTF-32 consistent with other UTF Charsets, making them available as `StandardCharsets`. A CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/java/nio/charset/StandardCharsets/Standard.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14599/files - new: https://git.openjdk.org/jdk/pull/14599/files/ccfc225c..0eb1df40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14599&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14599&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14599.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14599/head:pull/14599 PR: https://git.openjdk.org/jdk/pull/14599 From duke at openjdk.org Wed Jun 21 20:32:07 2023 From: duke at openjdk.org (Markus KARG) Date: Wed, 21 Jun 2023 20:32:07 GMT Subject: RFR: 8310426: (ch) Channels.newInputStream transferTo cleanup In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 15:15:51 GMT, Alan Bateman wrote: > ChannelInputStream, the InputStream returned by Channels.newInputStream, implements the transferTo method with support for the cross product of many interesting underlying channels. It's getting a bit too unwieldy and can be simplified by introducing a FileChannelInputStream to wrap a FileChannel. I am planning to provide optimizations for Channel-based Reader::transferTo in future, just like I did for InputStream::transferTo in the past. If we would have Channels::transfer(RBW, MBW) then I could simply reuse proven and trusted code. If we separate the code, then I have to provide (possibly several) new classes. I better understand and appreciate the merits of your new classes now thanks to you explanation, but it would be beneficial if the actual channel-to-channel algorithm could get reused. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14566#issuecomment-1601626871 From tprinzing at openjdk.org Wed Jun 21 22:46:20 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 21 Jun 2023 22:46:20 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events Message-ID: The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. In the java.base module: Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. In the jdk.jfr module: jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: Passed: jdk/jfr/event/io/TestSocketChannelEvents.java Passed: jdk/jfr/event/io/TestSocketEvents.java I added a micro benchmark which measures the overhead of handling the jfr socket events. test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk ------------- Commit messages: - some changes from review. - fix copyright date - Added micro benchmark to measure socket event overhead. - Some changes from review. - remove unnecessary cast - 8308995: Update Network IO JFR events to be static mirror events Changes: https://git.openjdk.org/jdk/pull/14342/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308995 Stats: 896 lines in 12 files changed: 523 ins; 367 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342 PR: https://git.openjdk.org/jdk/pull/14342 From alanb at openjdk.org Wed Jun 21 22:46:24 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jun 2023 22:46:24 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk src/java.base/share/classes/java/net/Socket.java line 43: > 41: import java.util.Collections; > 42: > 43: import jdk.internal.event.SocketWriteEvent; You'll probably want to clean up the imports to avoid having import of jdk.internal classes in two places. src/java.base/share/classes/java/net/Socket.java line 1109: > 1107: nbytes = read0(b, off, len); > 1108: } finally { > 1109: SocketReadEvent.checkForCommit(start, nbytes, parent.getRemoteSocketAddress(), parent.getSoTimeout()); So if read throws, this will commit a jdk.SocketReadEvent with size 0, maybe this will change later to include the exception? src/java.base/share/classes/java/net/Socket.java line 1114: > 1112: } > 1113: > 1114: private int read0(byte[] b, int off, int len) throws IOException { Can you rename this to implRead? src/java.base/share/classes/java/net/Socket.java line 1215: > 1213: return; > 1214: } > 1215: int bytesWritten = 0; Is bytesWritten needed? src/java.base/share/classes/java/net/Socket.java line 1226: > 1224: } > 1225: > 1226: public void write0(byte[] b, int off, int len) throws IOException { Can you change this to be private and rename to implWrite? src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 421: > 419: } > 420: > 421: private int read0(ByteBuffer buf) throws IOException { Can you rename this to implRead too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236731407 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237226982 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236719052 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236719603 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236719373 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237227861 From smarks at openjdk.org Wed Jun 21 22:46:25 2023 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 21 Jun 2023 22:46:25 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 09:46:35 GMT, Alan Bateman wrote: >> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk > > src/java.base/share/classes/java/net/Socket.java line 1114: > >> 1112: } >> 1113: >> 1114: private int read0(byte[] b, int off, int len) throws IOException { > > Can you rename this to implRead? Are we using a convention of `implRead` or `readImpl`? Either is ok with me, but I think we had been using `readImpl` and similar elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237316630 From alanb at openjdk.org Wed Jun 21 22:46:25 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jun 2023 22:46:25 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 16:59:22 GMT, Stuart Marks wrote: > Are we using a convention of `implRead` or `readImpl`? Either is ok with me, but I think we had been using `readImpl` and similar elsewhere. This code is already using implXXX so it's just be consistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237319486 From egahlin at openjdk.org Thu Jun 22 07:52:08 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 22 Jun 2023 07:52:08 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk I believe the fields SOCKET_READ and SOCKET_WRITE in the jdk.jfr.events.EventConfigurations class can be removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1602173783 From alanb at openjdk.org Thu Jun 22 10:25:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Jun 2023 10:25:09 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com> On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk src/java.base/share/classes/java/net/Socket.java line 1101: > 1099: @Override > 1100: public int read(byte[] b, int off, int len) throws IOException { > 1101: if (! SocketReadEvent.enabled()) { Drop the space in "! SocketReadEvent" as it is inconsistent with the existing code. src/java.base/share/classes/jdk/internal/event/SocketReadEvent.java line 119: > 117: public static void checkForCommit(long start, long nbytes, SocketAddress remote, long timeout) { > 118: long duration = timestamp() - start; > 119: if (shouldCommit(duration)) { I think you know this, but this will need to be re-examined for SocketChannel configured non-blocking. src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408: > 406: @Override > 407: public int read(ByteBuffer buf) throws IOException { > 408: if (!SocketReadEvent.enabled()) { The read/write with sun.nio.ch.SocketInputStream and SocketOutputStream does not go through SC.read/write so I think SocketAdaptor read/write will need attention, maybe a future PR as there are other code paths that aren't covered in this PR. src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 416: > 414: nbytes = implRead(buf); > 415: } finally { > 416: SocketReadEvent.checkForCommit(start, nbytes, getRemoteAddress(), 0); This will need to be changed to use remoteAddress(), can't use getRemoteAddress() as it might throw. src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 466: > 464: throws IOException > 465: { > 466: if (! SocketReadEvent.enabled()) { Spurious space here too, several other places. src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 474: > 472: nbytes = implRead(dsts, offset, length); > 473: } finally { > 474: SocketReadEvent.checkForCommit(start, nbytes, getRemoteAddress(), 0); This has to be remoteAddress() too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238312001 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238317470 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238323035 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238318572 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238318875 PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238319120 From alanb at openjdk.org Thu Jun 22 10:25:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Jun 2023 10:25:11 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: <-CBspYQOiQx_e5vmZhTtyJkmVQAyr129m3xJIlVJy3k=.f4b5bc13-35bf-4bfe-85df-a84fa8362186@github.com> On Wed, 21 Jun 2023 15:48:30 GMT, Alan Bateman wrote: >> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk > > src/java.base/share/classes/java/net/Socket.java line 1109: > >> 1107: nbytes = read0(b, off, len); >> 1108: } finally { >> 1109: SocketReadEvent.checkForCommit(start, nbytes, parent.getRemoteSocketAddress(), parent.getSoTimeout()); > > So if read throws, this will commit a jdk.SocketReadEvent with size 0, maybe this will change later to include the exception? The other issue to think about here is where the Socket is asynchronously closed. In t hat case, implRead will throw but we'll end up with a confusing suppressed exception due to the call to getSoTimeout. I think this will have to be replaced with a call to a helper method that returns the timeout or 0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238315000 From dfuchs at openjdk.org Thu Jun 22 11:57:04 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 22 Jun 2023 11:57:04 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk The new code seems to accurately correspond to what the various `*Instrumentor` classes were doing, so that is good. I agree with Alan that potential exception that may arise when generating the event are an issue (e.g. call to getRemoteAddress() or other getter that may make a check on the socket state) - though that was already present in the original code. Maybe that could be fixed here though. In cases where the implRead/implWrite call throws an exception, shouldn't the event contain that exception, or at least exception message? If it doesn't should it be emitted at all, or should another event be emitted instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1602505386 From egahlin at openjdk.org Thu Jun 22 13:43:04 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 22 Jun 2023 13:43:04 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 11:53:59 GMT, Daniel Fuchs wrote: > The new code seems to accurately correspond to what the various `*Instrumentor` classes were doing, so that is good. I agree with Alan that potential exception that may arise when generating the event are an issue (e.g. call to getRemoteAddress() or other getter that may make a check on the socket state) - though that was already present in the original code. Maybe that could be fixed here though. > In cases where the implRead/implWrite call throws an exception, shouldn't the event contain that exception, or at least exception message? If it doesn't should it be emitted at all, or should another event be emitted instead? An exception event will be emitted. The event is disabled by default, but there is ongoing work on a throttling mechanism, so it can be always-on. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1602659051 From bpb at openjdk.org Thu Jun 22 15:42:04 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Jun 2023 15:42:04 GMT Subject: RFR: 8310047: Add UTF-32 based Charsets into StandardCharsets [v2] In-Reply-To: <8-UxoxUg0sh7nGQKDWWqDWdWdvmkom3xmKK36f2UlN0=.e4979e04-4ae5-4a2c-8f28-ff2811a49067@github.com> References: <8-UxoxUg0sh7nGQKDWWqDWdWdvmkom3xmKK36f2UlN0=.e4979e04-4ae5-4a2c-8f28-ff2811a49067@github.com> Message-ID: On Wed, 21 Jun 2023 19:40:07 GMT, Naoto Sato wrote: >> To make UTF-32 consistent with other UTF Charsets, making them available as `StandardCharsets`. A CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/java/nio/charset/StandardCharsets/Standard.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14599#pullrequestreview-1493501835 From bpb at openjdk.org Thu Jun 22 18:30:13 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Jun 2023 18:30:13 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer Message-ID: Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. ------------- Commit messages: - 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer Changes: https://git.openjdk.org/jdk/pull/14616/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8222329 Stats: 17 lines in 3 files changed: 9 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616 PR: https://git.openjdk.org/jdk/pull/14616 From rriggs at openjdk.org Thu Jun 22 18:47:05 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 22 Jun 2023 18:47:05 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer In-Reply-To: References: Message-ID: <--HiX2f-DnBZU-SbmoFv9daOhvtGMdkMxA2T5mZ74Wo=.43ec1ed2-541f-4f84-a558-9b955e378ba4@github.com> On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter wrote: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1493807999 From bpb at openjdk.org Thu Jun 22 18:47:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Jun 2023 18:47:06 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter wrote: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. CSR will be filed if consensus is reached here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14616#issuecomment-1603144256 From lancea at openjdk.org Thu Jun 22 18:51:10 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 22 Jun 2023 18:51:10 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer In-Reply-To: References: Message-ID: <0qt0-5OxclIB-R6IFDSukdPydvxwT_tmzn9tKizO-Hc=.b439df6c-1dde-4568-8440-46f7fa355f04@github.com> On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter wrote: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. src/java.base/share/classes/java/lang/Readable.java line 49: > 47: * @param cb the buffer to read characters into > 48: * @return The number of {@code char} values added to the buffer, > 49: * possibly zero, or -1 if this source of characters is at its end Would it be clearer to specifically indicate 0 is returned when no characters will be read. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1238906635 From bpb at openjdk.org Thu Jun 22 19:04:04 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Jun 2023 19:04:04 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer In-Reply-To: <0qt0-5OxclIB-R6IFDSukdPydvxwT_tmzn9tKizO-Hc=.b439df6c-1dde-4568-8440-46f7fa355f04@github.com> References: <0qt0-5OxclIB-R6IFDSukdPydvxwT_tmzn9tKizO-Hc=.b439df6c-1dde-4568-8440-46f7fa355f04@github.com> Message-ID: On Thu, 22 Jun 2023 18:43:19 GMT, Lance Andersen wrote: >> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. > > src/java.base/share/classes/java/lang/Readable.java line 49: > >> 47: * @param cb the buffer to read characters into >> 48: * @return The number of {@code char} values added to the buffer, >> 49: * possibly zero, or -1 if this source of characters is at its end > > Would it be clearer to specifically indicate 0 is returned when no characters will be read. Might be. I was mimicking the return specification from [FileChannel::read](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/nio/channels/FileChannel.html#read(java.nio.ByteBuffer[],int,int)). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1238922106 From lancea at openjdk.org Thu Jun 22 19:19:05 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 22 Jun 2023 19:19:05 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer In-Reply-To: References: <0qt0-5OxclIB-R6IFDSukdPydvxwT_tmzn9tKizO-Hc=.b439df6c-1dde-4568-8440-46f7fa355f04@github.com> Message-ID: On Thu, 22 Jun 2023 19:00:58 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/lang/Readable.java line 49: >> >>> 47: * @param cb the buffer to read characters into >>> 48: * @return The number of {@code char} values added to the buffer, >>> 49: * possibly zero, or -1 if this source of characters is at its end >> >> Would it be clearer to specifically indicate 0 is returned when no characters will be read. > > Might be. I was mimicking the return specification from [FileChannel::read](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/nio/channels/FileChannel.html#read(java.nio.ByteBuffer[],int,int)). Consistency is probably good I guess in this case, though specifying `zero` vs `0` seems inconsistent when we specify `-1` as I believe this varies throughout the javadoc. But it matches the other javadoc so we are at least consistent (somewhat ) OK for now by me ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1238935203 From lancea at openjdk.org Thu Jun 22 19:19:03 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 22 Jun 2023 19:19:03 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter wrote: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1493850121 From bpb at openjdk.org Thu Jun 22 19:42:02 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Jun 2023 19:42:02 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter wrote: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. src/java.base/share/classes/java/io/Reader.java line 193: > 191: * changes made are the results of a put operation. No flipping or > 192: * rewinding of the buffer is performed. If the specified character > 193: * buffer is full, then no characters will be read and zero will be Instead of "is full" here, it would be more consistent to state "has no remaining elements". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1238953679 From bpb at openjdk.org Thu Jun 22 20:34:21 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Jun 2023 20:34:21 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v2] In-Reply-To: References: Message-ID: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8222329: rephrase "full" to "no elements remaining" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14616/files - new: https://git.openjdk.org/jdk/pull/14616/files/0fb2bf1f..ef650028 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=00-01 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616 PR: https://git.openjdk.org/jdk/pull/14616 From rriggs at openjdk.org Thu Jun 22 21:25:04 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 22 Jun 2023 21:25:04 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 19:39:16 GMT, Brian Burkhalter wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8222329: rephrase "full" to "no elements remaining" > > src/java.base/share/classes/java/io/Reader.java line 193: > >> 191: * changes made are the results of a put operation. No flipping or >> 192: * rewinding of the buffer is performed. If the specified character >> 193: * buffer is full, then no characters will be read and zero will be > > Instead of "is full" here, it would be more consistent to state "has no remaining elements". For a buffer that is being written into, it sounds a bit odd to say "no remaining elements"; that phrasing is ok for reading/getting bytes but doesn't sound like there's free space to put anything. Would "no remaining free elements" or "no remaining available elements" be better? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239042484 From bpb at openjdk.org Thu Jun 22 21:28:04 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Jun 2023 21:28:04 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 21:21:56 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/io/Reader.java line 193: >> >>> 191: * changes made are the results of a put operation. No flipping or >>> 192: * rewinding of the buffer is performed. If the specified character >>> 193: * buffer is full, then no characters will be read and zero will be >> >> Instead of "is full" here, it would be more consistent to state "has no remaining elements". > > For a buffer that is being written into, it sounds a bit odd to say "no remaining elements"; that phrasing is ok for reading/getting bytes but doesn't sound like there's free space to put anything. > > Would "no remaining free elements" or "no remaining available elements" be better? Or "no remaining space" / "no space remaining"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239045510 From rriggs at openjdk.org Thu Jun 22 21:41:03 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 22 Jun 2023 21:41:03 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 21:25:32 GMT, Brian Burkhalter wrote: >> For a buffer that is being written into, it sounds a bit odd to say "no remaining elements"; that phrasing is ok for reading/getting bytes but doesn't sound like there's free space to put anything. >> >> Would "no remaining free elements" or "no remaining available elements" be better? > > Or "no remaining space" / "no space remaining"? I have a slight preference for "no space remaining"; remaining can still be a linkplain to the method if that helps it be specific. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239054873 From bpb at openjdk.org Thu Jun 22 22:18:03 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Jun 2023 22:18:03 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 21:38:42 GMT, Roger Riggs wrote: >> Or "no remaining space" / "no space remaining"? > > I have a slight preference for "no space remaining"; remaining can still be a linkplain to the method if that helps it be specific. I concur. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239080155 From bpb at openjdk.org Thu Jun 22 22:24:23 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Jun 2023 22:24:23 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v3] In-Reply-To: References: Message-ID: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8222329: "elements remaining" -> "space remaining" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14616/files - new: https://git.openjdk.org/jdk/pull/14616/files/ef650028..055107bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616 PR: https://git.openjdk.org/jdk/pull/14616 From bpb at openjdk.org Thu Jun 22 22:52:23 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Jun 2023 22:52:23 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v4] In-Reply-To: References: Message-ID: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8222329: Correct return verbiage of Reader and CharBuffer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14616/files - new: https://git.openjdk.org/jdk/pull/14616/files/055107bd..d693c612 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616 PR: https://git.openjdk.org/jdk/pull/14616 From jlu at openjdk.org Fri Jun 23 00:03:04 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 23 Jun 2023 00:03:04 GMT Subject: RFR: 8310683: Refactor StandardCharset/standard.java to use JUnit Message-ID: Please review this PR which is apart of the migration of JDK tests to JUnit. Standard.java is refactored to use JUnit, and thus split up into the following tests. - typeTest - nameMethodTest - forNameMethodTest - charsetModifiersTest - correctCharsetsTest Additionally all unused methods were removed. ------------- Commit messages: - Additional cleanup - Refactor Standard.java to use JUnit + other cleanup - Fix imports and update copyright year Changes: https://git.openjdk.org/jdk/pull/14621/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14621&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310683 Stats: 118 lines in 1 file changed: 40 ins; 23 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/14621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14621/head:pull/14621 PR: https://git.openjdk.org/jdk/pull/14621 From naoto at openjdk.org Fri Jun 23 00:57:14 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 23 Jun 2023 00:57:14 GMT Subject: RFR: 8310683: Refactor StandardCharset/standard.java to use JUnit In-Reply-To: References: Message-ID: <1MJgJ-PE356a_r3o4Q7VyP72MUel3pTgE1heKUzAlFA=.1b2292e8-1681-432a-b916-9dc0cd83feef@github.com> On Thu, 22 Jun 2023 23:56:46 GMT, Justin Lu wrote: > Please review this PR which is apart of the migration of JDK tests to JUnit. Standard.java is refactored to use JUnit, and thus split up into the following tests. > > - typeTest > - nameMethodTest > - forNameMethodTest > - charsetModifiersTest > - correctCharsetsTest > > Additionally all unused methods were removed. Hi Justin, Would it be possible to make this PR a dependent PR of https://github.com/openjdk/jdk/pull/14599? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14621#issuecomment-1603488219 From alanb at openjdk.org Fri Jun 23 06:52:03 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Jun 2023 06:52:03 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 22:52:23 GMT, Brian Burkhalter wrote: >> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8222329: Correct return verbiage of Reader and CharBuffer src/java.base/share/classes/java/nio/X-Buffer.java.template line 484: > 482: * @throws ReadOnlyBufferException if target is a read only buffer, > 483: * even if it is empty > 484: * @since 1.5 It might be clearer if this method linked to the length method. That way it could be specified to return 0 when the length of the target buffer is 0. For the @throws of ROBE, probably need to avoid the word "empty", only because this method writes to the target buffer, it doesn't read from the target buffer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239387151 From jpai at openjdk.org Fri Jun 23 10:53:07 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 23 Jun 2023 10:53:07 GMT Subject: RFR: 8310047: Add UTF-32 based Charsets into StandardCharsets [v2] In-Reply-To: <8-UxoxUg0sh7nGQKDWWqDWdWdvmkom3xmKK36f2UlN0=.e4979e04-4ae5-4a2c-8f28-ff2811a49067@github.com> References: <8-UxoxUg0sh7nGQKDWWqDWdWdvmkom3xmKK36f2UlN0=.e4979e04-4ae5-4a2c-8f28-ff2811a49067@github.com> Message-ID: On Wed, 21 Jun 2023 19:40:07 GMT, Naoto Sato wrote: >> To make UTF-32 consistent with other UTF Charsets, making them available as `StandardCharsets`. A CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/java/nio/charset/StandardCharsets/Standard.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14599#pullrequestreview-1494915293 From bpb at openjdk.org Fri Jun 23 15:45:18 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Jun 2023 15:45:18 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v5] In-Reply-To: References: Message-ID: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8222329: Tweak verbiage some more ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14616/files - new: https://git.openjdk.org/jdk/pull/14616/files/d693c612..94505a45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=03-04 Stats: 10 lines in 3 files changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616 PR: https://git.openjdk.org/jdk/pull/14616 From bpb at openjdk.org Fri Jun 23 15:45:20 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Jun 2023 15:45:20 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v5] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 22:15:11 GMT, Brian Burkhalter wrote: >> I have a slight preference for "no space remaining"; remaining can still be a linkplain to the method if that helps it be specific. > > I concur. Thanks. Addressed in 055107bddcc38a331ee93e178402473ab9f91740. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239969934 From bpb at openjdk.org Fri Jun 23 15:45:24 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Jun 2023 15:45:24 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v4] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 06:49:31 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8222329: Correct return verbiage of Reader and CharBuffer > > src/java.base/share/classes/java/nio/X-Buffer.java.template line 484: > >> 482: * @throws ReadOnlyBufferException if target is a read only buffer, >> 483: * even if it is empty >> 484: * @since 1.5 > > It might be clearer if this method linked to the length method. That way it could be specified to return 0 when the length of the target buffer is 0. > > For the @throws of ROBE, probably need to avoid the word "empty", only because this method writes to the target buffer, it doesn't read from the target buffer. Addressed in 94505a45ce099faf3e31a07b8500ac456345a3b1; CSR not yet updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239968591 From jlu at openjdk.org Fri Jun 23 16:08:04 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 23 Jun 2023 16:08:04 GMT Subject: RFR: 8310683: Refactor StandardCharset/standard.java to use JUnit In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 23:56:46 GMT, Justin Lu wrote: > Please review this PR which is apart of the migration of JDK tests to JUnit. Standard.java is refactored to use JUnit, and thus split up into the following tests. > > - typeTest > - nameMethodTest > - forNameMethodTest > - charsetModifiersTest > - correctCharsetsTest > > Additionally all unused methods were removed. > Hi Justin, Would it be possible to make this PR a dependent PR of #14599? Hi Naoto, Of course, I will wait for you to integrate #14599, and update this PR accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14621#issuecomment-1604494031 From jlu at openjdk.org Fri Jun 23 16:10:03 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 23 Jun 2023 16:10:03 GMT Subject: RFR: 8310047: Add UTF-32 based Charsets into StandardCharsets [v2] In-Reply-To: <8-UxoxUg0sh7nGQKDWWqDWdWdvmkom3xmKK36f2UlN0=.e4979e04-4ae5-4a2c-8f28-ff2811a49067@github.com> References: <8-UxoxUg0sh7nGQKDWWqDWdWdvmkom3xmKK36f2UlN0=.e4979e04-4ae5-4a2c-8f28-ff2811a49067@github.com> Message-ID: On Wed, 21 Jun 2023 19:40:07 GMT, Naoto Sato wrote: >> To make UTF-32 consistent with other UTF Charsets, making them available as `StandardCharsets`. A CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/java/nio/charset/StandardCharsets/Standard.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14599#pullrequestreview-1495431095 From jlu at openjdk.org Fri Jun 23 16:30:23 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 23 Jun 2023 16:30:23 GMT Subject: RFR: 8310683: Refactor StandardCharset/standard.java to use JUnit [v2] In-Reply-To: References: Message-ID: > Please review this PR which is apart of the migration of JDK tests to JUnit. Standard.java is refactored to use JUnit, and thus split up into the following tests. > > - typeTest > - nameMethodTest > - forNameMethodTest > - charsetModifiersTest > - correctCharsetsTest > > Additionally all unused methods were removed. Justin Lu 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14621/files - new: https://git.openjdk.org/jdk/pull/14621/files/e7277ca0..e7277ca0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14621&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14621&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14621/head:pull/14621 PR: https://git.openjdk.org/jdk/pull/14621 From bpb at openjdk.org Fri Jun 23 16:36:16 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Jun 2023 16:36:16 GMT Subject: RFR: 8310682: No package-info (and @since) for package jdk.nio.mapmode Message-ID: Add `package-info.java` for package `jdk.nio.mapmode`. ------------- Commit messages: - 8310682: No package-info (and @since) for package jdk.nio.mapmode Changes: https://git.openjdk.org/jdk/pull/14628/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14628&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310682 Stats: 33 lines in 1 file changed: 33 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14628/head:pull/14628 PR: https://git.openjdk.org/jdk/pull/14628 From jlu at openjdk.org Fri Jun 23 16:41:10 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 23 Jun 2023 16:41:10 GMT Subject: RFR: 8310683: Refactor StandardCharset/standard.java to use JUnit [v3] In-Reply-To: References: Message-ID: <3Y2ZqbQYYW-e4DiMWkeznslSPLCiincgXYKgoj9Min4=.5038b3cb-8fa9-43db-b59a-41ed4b3c4344@github.com> > Please review this PR which is apart of the migration of JDK tests to JUnit. Standard.java is refactored to use JUnit, and thus split up into the following tests. > > - typeTest > - nameMethodTest > - forNameMethodTest > - charsetModifiersTest > - correctCharsetsTest > > Additionally all unused methods were removed. Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge pr/14599 - Additional cleanup - Refactor Standard.java to use JUnit + other cleanup - Fix imports and update copyright year - 8309685: Fix -Wconversion warnings in assembler and register code Reviewed-by: aph, fparain - 8310618: Test serviceability/sa/ClhsdbDumpclass.java fails after 8242152: 'StackMapTable:' missing from stdout/stderr Reviewed-by: kevinw, dholmes - 8310591: Missing `@since` tags in java.lang.foreign Reviewed-by: mcimadamore - 8310561: JFR: Unify decodeDescriptors(String, String) Reviewed-by: mgronlun - 8310549: avoid potential leaks in KeystoreImpl.m related to JNU_CHECK_EXCEPTION early returns Reviewed-by: weijun - 8242152: SA does not include StackMapTables when dumping .class files Reviewed-by: cjplummer, sspitsyn - ... and 9 more: https://git.openjdk.org/jdk/compare/0eb1df40...fbd49394 ------------- Changes: https://git.openjdk.org/jdk/pull/14621/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14621&range=02 Stats: 477 lines in 44 files changed: 175 ins; 80 del; 222 mod Patch: https://git.openjdk.org/jdk/pull/14621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14621/head:pull/14621 PR: https://git.openjdk.org/jdk/pull/14621 From alanb at openjdk.org Fri Jun 23 16:53:04 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Jun 2023 16:53:04 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v4] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 15:38:52 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/X-Buffer.java.template line 484: >> >>> 482: * @throws ReadOnlyBufferException if target is a read only buffer, >>> 483: * even if it is empty >>> 484: * @since 1.5 >> >> It might be clearer if this method linked to the length method. That way it could be specified to return 0 when the length of the target buffer is 0. >> >> For the @throws of ROBE, probably need to avoid the word "empty", only because this method writes to the target buffer, it doesn't read from the target buffer. > > Addressed in 94505a45ce099faf3e31a07b8500ac456345a3b1; CSR not yet updated. I checked the update but it now has "no source remaining or its length is zero". In CB, length == remaining so I think you just want one in the description. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240038493 From bpb at openjdk.org Fri Jun 23 17:10:07 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Jun 2023 17:10:07 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v4] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 16:50:28 GMT, Alan Bateman wrote: >> Addressed in 94505a45ce099faf3e31a07b8500ac456345a3b1; CSR not yet updated. > > I checked the update but it now has "no source remaining or its length is zero". In CB, length == remaining so I think you just want one in the description. Ah, good catch! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240057409 From bpb at openjdk.org Fri Jun 23 17:19:10 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Jun 2023 17:19:10 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v6] In-Reply-To: References: Message-ID: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8222329: Remove redundancy of length vs. remaining in CharBuffer::read doc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14616/files - new: https://git.openjdk.org/jdk/pull/14616/files/94505a45..7281b482 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616 PR: https://git.openjdk.org/jdk/pull/14616 From bpb at openjdk.org Fri Jun 23 17:19:12 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Jun 2023 17:19:12 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v4] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 17:07:34 GMT, Brian Burkhalter wrote: >> I checked the update but it now has "no source remaining or its length is zero". In CB, length == remaining so I think you just want one in the description. > > Ah, good catch! Fixed by 7281b482c24a3c74da15dbf637f7627c5dc5407b. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240066381 From naoto at openjdk.org Fri Jun 23 17:47:07 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 23 Jun 2023 17:47:07 GMT Subject: RFR: 8310047: Add UTF-32 based Charsets into StandardCharsets [v3] In-Reply-To: References: Message-ID: <251VeD1oyls2iUdzevu5jS_eRffGAZk-jFbCYSOUcMs=.d2e1e479-9b28-468c-95b4-d42fdbf815f9@github.com> > To make UTF-32 consistent with other UTF Charsets, making them available as `StandardCharsets`. A CSR has also been drafted. Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8310047-UTF-32 - Update test/jdk/java/nio/charset/StandardCharsets/Standard.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - 8310047: Add UTF-32 based Charsets into StandardCharsets ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14599/files - new: https://git.openjdk.org/jdk/pull/14599/files/0eb1df40..2ec12dc9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14599&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14599&range=01-02 Stats: 1063 lines in 96 files changed: 304 ins; 411 del; 348 mod Patch: https://git.openjdk.org/jdk/pull/14599.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14599/head:pull/14599 PR: https://git.openjdk.org/jdk/pull/14599 From lancea at openjdk.org Fri Jun 23 17:52:08 2023 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 23 Jun 2023 17:52:08 GMT Subject: RFR: 8310047: Add UTF-32 based Charsets into StandardCharsets [v3] In-Reply-To: <251VeD1oyls2iUdzevu5jS_eRffGAZk-jFbCYSOUcMs=.d2e1e479-9b28-468c-95b4-d42fdbf815f9@github.com> References: <251VeD1oyls2iUdzevu5jS_eRffGAZk-jFbCYSOUcMs=.d2e1e479-9b28-468c-95b4-d42fdbf815f9@github.com> Message-ID: On Fri, 23 Jun 2023 17:47:07 GMT, Naoto Sato wrote: >> To make UTF-32 consistent with other UTF Charsets, making them available as `StandardCharsets`. A CSR has also been drafted. > > Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8310047-UTF-32 > - Update test/jdk/java/nio/charset/StandardCharsets/Standard.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - 8310047: Add UTF-32 based Charsets into StandardCharsets Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14599#pullrequestreview-1495609398 From jlu at openjdk.org Fri Jun 23 18:00:16 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 23 Jun 2023 18:00:16 GMT Subject: RFR: 8310683: Refactor StandardCharset/standard.java to use JUnit [v4] In-Reply-To: References: Message-ID: > Please review this PR which is apart of the migration of JDK tests to JUnit. Standard.java is refactored to use JUnit, and thus split up into the following tests. > > - typeTest > - nameMethodTest > - forNameMethodTest > - charsetModifiersTest > - correctCharsetsTest > > Additionally all unused methods were removed. 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: - Merge branch 'pr/14599' of https://git.openjdk.org/jdk into JUnit-StandardCharsets - Merge pr/14599 - Additional cleanup - Refactor Standard.java to use JUnit + other cleanup - Fix imports and update copyright year ------------- Changes: https://git.openjdk.org/jdk/pull/14621/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14621&range=03 Stats: 118 lines in 1 file changed: 31 ins; 20 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/14621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14621/head:pull/14621 PR: https://git.openjdk.org/jdk/pull/14621 From naoto at openjdk.org Fri Jun 23 18:46:08 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 23 Jun 2023 18:46:08 GMT Subject: RFR: 8310683: Refactor StandardCharset/standard.java to use JUnit [v4] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 18:00:16 GMT, Justin Lu wrote: >> Please review this PR which is apart of the migration of JDK tests to JUnit. Standard.java is refactored to use JUnit, and thus split up into the following tests. >> >> - typeTest >> - nameMethodTest >> - forNameMethodTest >> - charsetModifiersTest >> - correctCharsetsTest >> >> Additionally all unused methods were removed. > > 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: > > - Merge branch 'pr/14599' of https://git.openjdk.org/jdk into JUnit-StandardCharsets > - Merge pr/14599 > - Additional cleanup > - Refactor Standard.java to use JUnit + other cleanup > - Fix imports and update copyright year test/jdk/java/nio/charset/StandardCharsets/Standard.java line 115: > 113: public void correctCharsetsTest() { > 114: // Grab the value from each Standard Charset field > 115: List actualCharsets = Arrays.stream(StandardCharsets.class.getFields()).map(field -> { Can `charsetFields()` be used here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14621#discussion_r1240177911 From rriggs at openjdk.org Fri Jun 23 20:40:17 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 23 Jun 2023 20:40:17 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v6] In-Reply-To: References: Message-ID: <3DX4IBEr8sb827WoGKZElT7bg7t1n7sToPe-K6IFsn8=.25829915-bf02-4e3f-b9c5-65621d9d9ff9@github.com> On Fri, 23 Jun 2023 17:19:10 GMT, Brian Burkhalter wrote: >> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8222329: Remove redundancy of length vs. remaining in CharBuffer::read doc Looks good but for one typo. src/java.base/share/classes/java/io/Reader.java line 194: > 192: * rewinding of the buffer is performed. If the specified character > 193: * buffer has no space {@linkplain java.nio.Buffer#hasRemaining > 194: * remaining} or or its {@linkplain java.nio.CharBuffer#length length} typo: "or or" -> "or" ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1495972372 PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240353636 From jlu at openjdk.org Fri Jun 23 20:45:17 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 23 Jun 2023 20:45:17 GMT Subject: RFR: 8310683: Refactor StandardCharset/standard.java to use JUnit [v4] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 18:43:16 GMT, Naoto Sato 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: >> >> - Merge branch 'pr/14599' of https://git.openjdk.org/jdk into JUnit-StandardCharsets >> - Merge pr/14599 >> - Additional cleanup >> - Refactor Standard.java to use JUnit + other cleanup >> - Fix imports and update copyright year > > test/jdk/java/nio/charset/StandardCharsets/Standard.java line 115: > >> 113: public void correctCharsetsTest() { >> 114: // Grab the value from each Standard Charset field >> 115: List actualCharsets = Arrays.stream(StandardCharsets.class.getFields()).map(field -> { > > Can `charsetFields()` be used here? Good point, changed so that the fields are reused, and `correctCharsetsTest()` calls `charsetFields()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14621#discussion_r1240360338 From jlu at openjdk.org Fri Jun 23 20:45:14 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 23 Jun 2023 20:45:14 GMT Subject: RFR: 8310683: Refactor StandardCharset/standard.java to use JUnit [v5] In-Reply-To: References: Message-ID: > Please review this PR which is apart of the migration of JDK tests to JUnit. Standard.java is refactored to use JUnit, and thus split up into the following tests. > > - typeTest > - nameMethodTest > - forNameMethodTest > - charsetModifiersTest > - correctCharsetsTest > > Additionally all unused methods were removed. Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - Just use charsetFields() - Review: reuse the standard charset fields ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14621/files - new: https://git.openjdk.org/jdk/pull/14621/files/86c86cad..0ac05e25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14621&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14621&range=03-04 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14621/head:pull/14621 PR: https://git.openjdk.org/jdk/pull/14621 From bpb at openjdk.org Fri Jun 23 20:49:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Jun 2023 20:49:06 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v6] In-Reply-To: <3DX4IBEr8sb827WoGKZElT7bg7t1n7sToPe-K6IFsn8=.25829915-bf02-4e3f-b9c5-65621d9d9ff9@github.com> References: <3DX4IBEr8sb827WoGKZElT7bg7t1n7sToPe-K6IFsn8=.25829915-bf02-4e3f-b9c5-65621d9d9ff9@github.com> Message-ID: On Fri, 23 Jun 2023 20:36:59 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8222329: Remove redundancy of length vs. remaining in CharBuffer::read doc > > src/java.base/share/classes/java/io/Reader.java line 194: > >> 192: * rewinding of the buffer is performed. If the specified character >> 193: * buffer has no space {@linkplain java.nio.Buffer#hasRemaining >> 194: * remaining} or or its {@linkplain java.nio.CharBuffer#length length} > > typo: "or or" -> "or" Bummer. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240371637 From bpb at openjdk.org Fri Jun 23 20:56:14 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Jun 2023 20:56:14 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v7] In-Reply-To: References: Message-ID: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8222329: "or or" -> "or" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14616/files - new: https://git.openjdk.org/jdk/pull/14616/files/7281b482..8bcf4674 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616 PR: https://git.openjdk.org/jdk/pull/14616 From bpb at openjdk.org Fri Jun 23 20:56:16 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Jun 2023 20:56:16 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v6] In-Reply-To: References: <3DX4IBEr8sb827WoGKZElT7bg7t1n7sToPe-K6IFsn8=.25829915-bf02-4e3f-b9c5-65621d9d9ff9@github.com> Message-ID: On Fri, 23 Jun 2023 20:46:29 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/Reader.java line 194: >> >>> 192: * rewinding of the buffer is performed. If the specified character >>> 193: * buffer has no space {@linkplain java.nio.Buffer#hasRemaining >>> 194: * remaining} or or its {@linkplain java.nio.CharBuffer#length length} >> >> typo: "or or" -> "or" > > Bummer. Thanks. Fixed by 8bcf4674c24f72401ab80564541d724336a60d79. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240379682 From rriggs at openjdk.org Fri Jun 23 21:01:06 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 23 Jun 2023 21:01:06 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v7] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 20:56:14 GMT, Brian Burkhalter wrote: >> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8222329: "or or" -> "or" Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1496016282 From naoto at openjdk.org Fri Jun 23 21:07:04 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 23 Jun 2023 21:07:04 GMT Subject: RFR: 8310683: Refactor StandardCharset/standard.java to use JUnit [v5] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 20:45:14 GMT, Justin Lu wrote: >> Please review this PR which is apart of the migration of JDK tests to JUnit. Standard.java is refactored to use JUnit, and thus split up into the following tests. >> >> - typeTest >> - nameMethodTest >> - forNameMethodTest >> - charsetModifiersTest >> - correctCharsetsTest >> >> Additionally all unused methods were removed. > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Just use charsetFields() > - Review: reuse the standard charset fields Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14621#pullrequestreview-1496024461 From bpb at openjdk.org Fri Jun 23 23:23:07 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Jun 2023 23:23:07 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v8] In-Reply-To: References: Message-ID: <9zcG8qlnoueAaovh9GHXuR7hmauDCN6mGW0CfXZcnHQ=.73d44ff2-a5b9-4949-aa00-2b9c9fe9ccc7@github.com> > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8222329: Disambiguate length/remaining in Reader and Readable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14616/files - new: https://git.openjdk.org/jdk/pull/14616/files/8bcf4674..12f982b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=06-07 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616 PR: https://git.openjdk.org/jdk/pull/14616 From lancea at openjdk.org Sat Jun 24 00:55:11 2023 From: lancea at openjdk.org (Lance Andersen) Date: Sat, 24 Jun 2023 00:55:11 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v8] In-Reply-To: <9zcG8qlnoueAaovh9GHXuR7hmauDCN6mGW0CfXZcnHQ=.73d44ff2-a5b9-4949-aa00-2b9c9fe9ccc7@github.com> References: <9zcG8qlnoueAaovh9GHXuR7hmauDCN6mGW0CfXZcnHQ=.73d44ff2-a5b9-4949-aa00-2b9c9fe9ccc7@github.com> Message-ID: On Fri, 23 Jun 2023 23:23:07 GMT, Brian Burkhalter wrote: >> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8222329: Disambiguate length/remaining in Reader and Readable Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1496255190 From alanb at openjdk.org Sat Jun 24 05:21:04 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Jun 2023 05:21:04 GMT Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v8] In-Reply-To: <9zcG8qlnoueAaovh9GHXuR7hmauDCN6mGW0CfXZcnHQ=.73d44ff2-a5b9-4949-aa00-2b9c9fe9ccc7@github.com> References: <9zcG8qlnoueAaovh9GHXuR7hmauDCN6mGW0CfXZcnHQ=.73d44ff2-a5b9-4949-aa00-2b9c9fe9ccc7@github.com> Message-ID: On Fri, 23 Jun 2023 23:23:07 GMT, Brian Burkhalter wrote: >> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8222329: Disambiguate length/remaining in Reader and Readable Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1496353176 From alanb at openjdk.org Sat Jun 24 05:28:04 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Jun 2023 05:28:04 GMT Subject: RFR: 8310682: No package-info (and @since) for package jdk.nio.mapmode In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 16:30:15 GMT, Brian Burkhalter wrote: > Add `package-info.java` for package `jdk.nio.mapmode`. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14628#pullrequestreview-1496355363 From bpb at openjdk.org Mon Jun 26 16:32:10 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 26 Jun 2023 16:32:10 GMT Subject: Integrated: 8310682: No package-info (and @since) for package jdk.nio.mapmode In-Reply-To: References: Message-ID: <1p_gsWD60Skm0tSheSK_v2sIwO4lch14jY0E1u1ZSV4=.e52249fc-74e8-40c8-92cc-52d73de23c04@github.com> On Fri, 23 Jun 2023 16:30:15 GMT, Brian Burkhalter wrote: > Add `package-info.java` for package `jdk.nio.mapmode`. This pull request has now been integrated. Changeset: d32eb015 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/d32eb015f056b09fa9ae99a2a84b7056cd3d9259 Stats: 33 lines in 1 file changed: 33 ins; 0 del; 0 mod 8310682: No package-info (and @since) for package jdk.nio.mapmode Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/14628 From alanb at openjdk.org Tue Jun 27 06:09:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 Jun 2023 06:09:36 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues Message-ID: This change fixes a number of bugs with FileChannel.transferTo/transerFrom that arise when the source or target channel is closed, or the thread is interrupted, during the transfer. More specifically: - The direct implementations operate on the raw file descriptor and don't prevent the target/source channel from being closed during the transfer. For this PR, the direct transferTo is limited to cases where the target is a FileChannel or SocketChannel. It could be extended to other SelChImpl implementations (SinkChannel, DatagramChannel) if needed, but they are less interesting at this time. - The transferTo/transferFrom methods are specified to throw ClosedByInterruptException after closing both channels. This is implemented inconsistently, and leaves one channel open in several cases. ------------- Commit messages: - Update - Update - Initial commit Changes: https://git.openjdk.org/jdk/pull/14656/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14656&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310902 Stats: 850 lines in 3 files changed: 662 ins; 84 del; 104 mod Patch: https://git.openjdk.org/jdk/pull/14656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14656/head:pull/14656 PR: https://git.openjdk.org/jdk/pull/14656 From bpb at openjdk.org Tue Jun 27 06:09:36 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 27 Jun 2023 06:09:36 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 17:14:15 GMT, Alan Bateman wrote: > This change fixes a number of bugs with FileChannel.transferTo/transerFrom that arise when the source or target channel is closed, or the thread is interrupted, during the transfer. More specifically: > > - The direct implementations operate on the raw file descriptor and don't prevent the target/source channel from being closed during the transfer. For this PR, the direct transferTo is limited to cases where the target is a FileChannel or SocketChannel. It could be extended to other SelChImpl implementations (SinkChannel, DatagramChannel) if needed, but they are less interesting at this time. > > - The transferTo/transferFrom methods are specified to throw ClosedByInterruptException after closing both channels. This is implemented inconsistently, and leaves one channel open in several cases. src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 547: > 545: } > 546: > 547: // Assume at first that the underlying kernel supports sendfile(); It's not just sendfile() any more so maybe this comment should be broadened. src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 552: > 550: private static volatile boolean transferToDirectNotSupported; > 551: > 552: // Assume that the underlying kernel sendfile() will work if the target This comment could be broadened as well. test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java line 194: > 192: @ParameterizedTest > 193: @MethodSource("sources") > 194: void testInterruptTransferDuring(ReadableByteChannel src) throws Exception { I think this method must've been intended to be named `testInterruptDuringTransferFrom`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1242889248 PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1242889487 PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1242866175 From alanb at openjdk.org Tue Jun 27 07:46:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 Jun 2023 07:46:57 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v2] In-Reply-To: References: Message-ID: > This change fixes a number of bugs with FileChannel.transferTo/transerFrom that arise when the source or target channel is closed, or the thread is interrupted, during the transfer. More specifically: > > - The direct implementations operate on the raw file descriptor and don't prevent the target/source channel from being closed during the transfer. For this PR, the direct transferTo is limited to cases where the target is a FileChannel or SocketChannel. It could be extended to other SelChImpl implementations (SinkChannel, DatagramChannel) if needed, but they are less interesting at this time. > > - The transferTo/transferFrom methods are specified to throw ClosedByInterruptException after closing both channels. This is implemented inconsistently, and leaves one channel open in several cases. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: More robustness ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14656/files - new: https://git.openjdk.org/jdk/pull/14656/files/d4ba2d05..d5d8f742 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14656&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14656&range=00-01 Stats: 28 lines in 2 files changed: 11 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/14656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14656/head:pull/14656 PR: https://git.openjdk.org/jdk/pull/14656 From alanb at openjdk.org Tue Jun 27 07:46:59 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 Jun 2023 07:46:59 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 22:44:58 GMT, Brian Burkhalter wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> More robustness > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 547: > >> 545: } >> 546: >> 547: // Assume at first that the underlying kernel supports sendfile(); > > It's not just sendfile() any more so maybe this comment should be broadened. This PR doesn't change which syscalls are used but I agree that this comment is a bit outdated, we can make it sendfile/equivalent to avoid enumerating the different syscalls and implementations that can be used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1243280321 From bpb at openjdk.org Tue Jun 27 15:31:14 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 27 Jun 2023 15:31:14 GMT Subject: Integrated: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter wrote: > Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. This pull request has now been integrated. Changeset: 58bb6555 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/58bb6555e783e4627f57c3c8281183c474d581c9 Stats: 23 lines in 3 files changed: 11 ins; 0 del; 12 mod 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer Reviewed-by: rriggs, lancea, alanb ------------- PR: https://git.openjdk.org/jdk/pull/14616 From bpb at openjdk.org Tue Jun 27 15:47:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 27 Jun 2023 15:47:06 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 07:41:28 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 547: >> >>> 545: } >>> 546: >>> 547: // Assume at first that the underlying kernel supports sendfile(); >> >> It's not just sendfile() any more so maybe this comment should be broadened. > > This PR doesn't change which syscalls are used but I agree that this comment is a bit outdated, we can make it sendfile/equivalent to avoid enumerating the different syscalls and implementations that can be used. Sounds good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1243970921 From tprinzing at openjdk.org Tue Jun 27 18:32:05 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 27 Jun 2023 18:32:05 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com> References: <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com> Message-ID: On Thu, 22 Jun 2023 10:21:46 GMT, Alan Bateman wrote: >> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk > > src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408: > >> 406: @Override >> 407: public int read(ByteBuffer buf) throws IOException { >> 408: if (!SocketReadEvent.enabled()) { > > The read/write with sun.nio.ch.SocketInputStream and SocketOutputStream does not go through SC.read/write so I think SocketAdaptor read/write will need attention, maybe a future PR as there are other code paths that aren't covered in this PR. I've created https://bugs.openjdk.org/browse/JDK-8310978 to drive the future PR to support the missing code paths ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1244182424 From tprinzing at openjdk.org Tue Jun 27 18:45:04 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 27 Jun 2023 18:45:04 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin wrote: > In cases where the implRead/implWrite call throws an exception, shouldn't the event contain that exception, or at least exception message? If it doesn't should it be emitted at all, or should another event be emitted instead? Added issue https://bugs.openjdk.org/browse/JDK-8310979 to add a field to SocketReadEvent and SocketWriteEvent in a separate PR ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1610037645 From tprinzing at openjdk.org Tue Jun 27 21:06:54 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 27 Jun 2023 21:06:54 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v2] In-Reply-To: References: Message-ID: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: Avoid exceptions getting address/timeout for jfr event. Remove unused EventConiguration fields SOCKET_READ and SOCKET_WRITE. Remove spurious whitespace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14342/files - new: https://git.openjdk.org/jdk/pull/14342/files/5faeb300..518adf8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=00-01 Stats: 21 lines in 3 files changed: 10 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/14342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342 PR: https://git.openjdk.org/jdk/pull/14342 From tprinzing at openjdk.org Tue Jun 27 21:52:08 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 27 Jun 2023 21:52:08 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v3] In-Reply-To: References: Message-ID: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - remove unused SOCKET_READ and SOCKET_WRITE configurations. - Merge branch 'master' into JDK-8308995 # Conflicts: # src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java - Avoid exceptions getting address/timeout for jfr event. Remove unused EventConiguration fields SOCKET_READ and SOCKET_WRITE. Remove spurious whitespace. - some changes from review. read0() to implRead() write0() to implWrite() trailing whitespace - fix copyright date - Added micro benchmark to measure socket event overhead. - Some changes from review. Append a 0 to method names being wrapped. Use getHostString to avoid a reverse lookup when fetching the hostname of the remote address. - remove unnecessary cast - 8308995: Update Network IO JFR events to be static mirror events ------------- Changes: https://git.openjdk.org/jdk/pull/14342/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=02 Stats: 908 lines in 13 files changed: 533 ins; 369 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342 PR: https://git.openjdk.org/jdk/pull/14342 From alanb at openjdk.org Wed Jun 28 06:12:12 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Jun 2023 06:12:12 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 21:52:08 GMT, Tim Prinzing wrote: >> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk > > Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - remove unused SOCKET_READ and SOCKET_WRITE configurations. > - Merge branch 'master' into JDK-8308995 > > # Conflicts: > # src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java > - Avoid exceptions getting address/timeout for jfr event. Remove unused > EventConiguration fields SOCKET_READ and SOCKET_WRITE. Remove spurious > whitespace. > - some changes from review. > > read0() to implRead() > write0() to implWrite() > trailing whitespace > - fix copyright date > - Added micro benchmark to measure socket event overhead. > - Some changes from review. > > Append a 0 to method names being wrapped. Use getHostString to avoid > a reverse lookup when fetching the hostname of the remote address. > - remove unnecessary cast > - 8308995: Update Network IO JFR events to be static mirror events src/java.base/share/classes/java/net/Socket.java line 1133: > 1131: return parent.getSoTimeout(); > 1132: } catch (Throwable t) { > 1133: // ignored - avoiding exceptions in jfr event data gathering This should be SocketException, not Throwable. That said, I think it would be useful to know why the SocketReadEvent includes the timeout. Is this used to see If read durations are close to the timeout? I assume once this code is fixed to deal with the exceptional case that the need to include the timeout for the success case will mostly go away. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1244728684 From alanb at openjdk.org Wed Jun 28 06:18:35 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Jun 2023 06:18:35 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v3] In-Reply-To: References: Message-ID: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> > This change fixes a number of bugs with FileChannel.transferTo/transerFrom that arise when the source or target channel is closed, or the thread is interrupted, during the transfer. More specifically: > > - The direct implementations operate on the raw file descriptor and don't prevent the target/source channel from being closed during the transfer. For this PR, the direct transferTo is limited to cases where the target is a FileChannel or SocketChannel. It could be extended to other SelChImpl implementations (SinkChannel, DatagramChannel) if needed, but they are less interesting at this time. > > - The transferTo/transferFrom methods are specified to throw ClosedByInterruptException after closing both channels. This is implemented inconsistently, and leaves one channel open in several cases. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge - Make transferFromDirect more consistent - Merge - More robustness - Update - Update - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14656/files - new: https://git.openjdk.org/jdk/pull/14656/files/d5d8f742..639372ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14656&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14656&range=01-02 Stats: 7767 lines in 311 files changed: 2910 ins; 2345 del; 2512 mod Patch: https://git.openjdk.org/jdk/pull/14656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14656/head:pull/14656 PR: https://git.openjdk.org/jdk/pull/14656 From bpb at openjdk.org Wed Jun 28 16:45:57 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Jun 2023 16:45:57 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v3] In-Reply-To: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> References: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> Message-ID: On Wed, 28 Jun 2023 06:18:35 GMT, Alan Bateman wrote: >> This change fixes a number of bugs with FileChannel.transferTo/transerFrom that arise when the source or target channel is closed, or the thread is interrupted, during the transfer. More specifically: >> >> - The direct implementations operate on the raw file descriptor and don't prevent the target/source channel from being closed during the transfer. For this PR, the direct transferTo is limited to cases where the target is a FileChannel or SocketChannel. It could be extended to other SelChImpl implementations (SinkChannel, DatagramChannel) if needed, but they are less interesting at this time. >> >> - The transferTo/transferFrom methods are specified to throw ClosedByInterruptException after closing both channels. This is implemented inconsistently, and leaves one channel open in several cases. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge > - Make transferFromDirect more consistent > - Merge > - More robustness > - Update > - Update > - Initial commit test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java line 194: > 192: @ParameterizedTest > 193: @MethodSource("sources") > 194: void testInterruptTransferDuringTransferFrom(ReadableByteChannel src) throws Exception { Should this be instead `testInterruptTransferDuringTransferFrom` for consistency with `testInterruptDuringTransferTo`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1245495216 From alanb at openjdk.org Wed Jun 28 17:03:10 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Jun 2023 17:03:10 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v3] In-Reply-To: References: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> Message-ID: On Wed, 28 Jun 2023 16:43:10 GMT, Brian Burkhalter wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge >> - Make transferFromDirect more consistent >> - Merge >> - More robustness >> - Update >> - Update >> - Initial commit > > test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java line 194: > >> 192: @ParameterizedTest >> 193: @MethodSource("sources") >> 194: void testInterruptTransferDuringTransferFrom(ReadableByteChannel src) throws Exception { > > Should this be instead `testInterruptTransferDuringTransferFrom` for consistency with `testInterruptDuringTransferTo`? Is there a typo here, I can't quite see it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1245515990 From lkorinth at openjdk.org Wed Jun 28 17:04:24 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 28 Jun 2023 17:04:24 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files Message-ID: Remove trailing "blank" lines in source files. I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. The fix removes trailing lines matching ^[[:space:]]*$ in - *.java - *.cpp - *.hpp - *.c - *.h I have applied the following bash script to each file: file="$1" while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do truncate -s -1 "$file" done `git diff --ignore-space-change --ignore-blank-lines master` displays no changes `git diff --ignore-blank-lines master` displays one change ------------- Commit messages: - h - c - hpp - cpp - 8311043: Remove trailing blank lines in source files Changes: https://git.openjdk.org/jdk/pull/14698/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14698&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311043 Stats: 4529 lines in 4382 files changed: 0 ins; 4529 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14698/head:pull/14698 PR: https://git.openjdk.org/jdk/pull/14698 From bpb at openjdk.org Wed Jun 28 17:34:01 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Jun 2023 17:34:01 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v3] In-Reply-To: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> References: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> Message-ID: <3kdZVGLMl_ZRnskoJOQkGFdoNJ9k506FCDdNHKpUA0Q=.393f62ca-c5a3-49b5-b8fc-9315adb609b8@github.com> On Wed, 28 Jun 2023 06:18:35 GMT, Alan Bateman wrote: >> This change fixes a number of bugs with FileChannel.transferTo/transerFrom that arise when the source or target channel is closed, or the thread is interrupted, during the transfer. More specifically: >> >> - The direct implementations operate on the raw file descriptor and don't prevent the target/source channel from being closed during the transfer. For this PR, the direct transferTo is limited to cases where the target is a FileChannel or SocketChannel. It could be extended to other SelChImpl implementations (SinkChannel, DatagramChannel) if needed, but they are less interesting at this time. >> >> - The transferTo/transferFrom methods are specified to throw ClosedByInterruptException after closing both channels. This is implemented inconsistently, and leaves one channel open in several cases. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge > - Make transferFromDirect more consistent > - Merge > - More robustness > - Update > - Update > - Initial commit src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 561: > 559: * @throws ClosedChannelException if channel is closed > 560: */ > 561: private int beforeTransfer() throws ClosedChannelException { Should this method and `afterTransfer()` be moved up before the `*NotSupported` fields as they cover transferring both to and from? // beforeTransfer() // afterTransfer() // transferTo fields and methods // transferFrom fields and methods ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1245549597 From alanb at openjdk.org Wed Jun 28 17:41:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Jun 2023 17:41:57 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v3] In-Reply-To: <3kdZVGLMl_ZRnskoJOQkGFdoNJ9k506FCDdNHKpUA0Q=.393f62ca-c5a3-49b5-b8fc-9315adb609b8@github.com> References: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> <3kdZVGLMl_ZRnskoJOQkGFdoNJ9k506FCDdNHKpUA0Q=.393f62ca-c5a3-49b5-b8fc-9315adb609b8@github.com> Message-ID: <72_Z-bpQe_KEfg4OtEQSIQeS2eyO_g6eSLu18HFDHh0=.11ca5c90-1c62-4d7c-92e3-95053d49da94@github.com> On Wed, 28 Jun 2023 17:31:12 GMT, Brian Burkhalter wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge >> - Make transferFromDirect more consistent >> - Merge >> - More robustness >> - Update >> - Update >> - Initial commit > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 561: > >> 559: * @throws ClosedChannelException if channel is closed >> 560: */ >> 561: private int beforeTransfer() throws ClosedChannelException { > > Should this method and `afterTransfer()` be moved up before the `*NotSupported` fields as they cover transferring both to and from? > > // beforeTransfer() > // afterTransfer() > // transferTo fields and methods > // transferFrom fields and methods Alternatively, transferFromNotSupported; can be moved up so that the transfer flags are in one place. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1245557758 From bpb at openjdk.org Wed Jun 28 18:11:55 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Jun 2023 18:11:55 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v3] In-Reply-To: <72_Z-bpQe_KEfg4OtEQSIQeS2eyO_g6eSLu18HFDHh0=.11ca5c90-1c62-4d7c-92e3-95053d49da94@github.com> References: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> <3kdZVGLMl_ZRnskoJOQkGFdoNJ9k506FCDdNHKpUA0Q=.393f62ca-c5a3-49b5-b8fc-9315adb609b8@github.com> <72_Z-bpQe_KEfg4OtEQSIQeS2eyO_g6eSLu18HFDHh0=.11ca5c90-1c62-4d7c-92e3-95053d49da94@github.com> Message-ID: On Wed, 28 Jun 2023 17:39:19 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 561: >> >>> 559: * @throws ClosedChannelException if channel is closed >>> 560: */ >>> 561: private int beforeTransfer() throws ClosedChannelException { >> >> Should this method and `afterTransfer()` be moved up before the `*NotSupported` fields as they cover transferring both to and from? >> >> // beforeTransfer() >> // afterTransfer() >> // transferTo fields and methods >> // transferFrom fields and methods > > Alternatively, transferFromNotSupported; can be moved up so that the transfer flags are in one place. Either way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1245586719 From bpb at openjdk.org Wed Jun 28 18:11:59 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Jun 2023 18:11:59 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v3] In-Reply-To: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> References: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> Message-ID: On Wed, 28 Jun 2023 06:18:35 GMT, Alan Bateman wrote: >> This change fixes a number of bugs with FileChannel.transferTo/transerFrom that arise when the source or target channel is closed, or the thread is interrupted, during the transfer. More specifically: >> >> - The direct implementations operate on the raw file descriptor and don't prevent the target/source channel from being closed during the transfer. For this PR, the direct transferTo is limited to cases where the target is a FileChannel or SocketChannel. It could be extended to other SelChImpl implementations (SinkChannel, DatagramChannel) if needed, but they are less interesting at this time. >> >> - The transferTo/transferFrom methods are specified to throw ClosedByInterruptException after closing both channels. This is implemented inconsistently, and leaves one channel open in several cases. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge > - Make transferFromDirect more consistent > - Merge > - More robustness > - Update > - Update > - Initial commit src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 657: > 655: long n = transferToFileDescriptor(position, count, target.fd); > 656: if (n == IOStatus.UNSUPPORTED_CASE) { > 657: transferToFileDirectNotSupported = true; On Linux, `transferToFileDescriptor` will fail with `UNSUPPORTED_CASE` if the target is open for appending. I don't think that this should mean that all future fast transfers to a file should be suppressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1245585805 From alanb at openjdk.org Wed Jun 28 18:37:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Jun 2023 18:37:57 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v3] In-Reply-To: References: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> Message-ID: On Wed, 28 Jun 2023 18:07:58 GMT, Brian Burkhalter wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge >> - Make transferFromDirect more consistent >> - Merge >> - More robustness >> - Update >> - Update >> - Initial commit > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 657: > >> 655: long n = transferToFileDescriptor(position, count, target.fd); >> 656: if (n == IOStatus.UNSUPPORTED_CASE) { >> 657: transferToFileDirectNotSupported = true; > > On Linux, `transferToFileDescriptor` will fail with `UNSUPPORTED_CASE` if the target is open for appending. I don't think that this should mean that all future fast transfers to a file should be suppressed. I'll check it but all I've really done here is rename fileSupported to transferToFileDirectNotSupported and inverted the values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1245610113 From tprinzing at openjdk.org Wed Jun 28 18:53:12 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 28 Jun 2023 18:53:12 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: Message-ID: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: less exception filtering when fetching socket read timeout ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14342/files - new: https://git.openjdk.org/jdk/pull/14342/files/27a766c7..d6f7df72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342 PR: https://git.openjdk.org/jdk/pull/14342 From bpb at openjdk.org Wed Jun 28 19:09:54 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Jun 2023 19:09:54 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v3] In-Reply-To: References: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> Message-ID: On Wed, 28 Jun 2023 18:34:47 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 657: >> >>> 655: long n = transferToFileDescriptor(position, count, target.fd); >>> 656: if (n == IOStatus.UNSUPPORTED_CASE) { >>> 657: transferToFileDirectNotSupported = true; >> >> On Linux, `transferToFileDescriptor` will fail with `UNSUPPORTED_CASE` if the target is open for appending. I don't think that this should mean that all future fast transfers to a file should be suppressed. > > I'll check it but all I've really done here is rename fileSupported to transferToFileDirectNotSupported and inverted the values. In that case the situation did not change and whether it poses a problem could be investigated under another issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1245642266 From alanb at openjdk.org Wed Jun 28 19:46:13 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Jun 2023 19:46:13 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v4] In-Reply-To: References: Message-ID: <3G4_QQsJC7TOfs39NwRNU8hKmDC2zt--l5LMmuZjPW0=.b0c8d30e-275a-487d-9fba-7e5fcefe1538@github.com> > This change fixes a number of bugs with FileChannel.transferTo/transerFrom that arise when the source or target channel is closed, or the thread is interrupted, during the transfer. More specifically: > > - The direct implementations operate on the raw file descriptor and don't prevent the target/source channel from being closed during the transfer. For this PR, the direct transferTo is limited to cases where the target is a FileChannel or SocketChannel. It could be extended to other SelChImpl implementations (SinkChannel, DatagramChannel) if needed, but they are less interesting at this time. > > - The transferTo/transferFrom methods are specified to throw ClosedByInterruptException after closing both channels. This is implemented inconsistently, and leaves one channel open in several cases. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Cleanup transferToDirectNotSupported/transferFromDirectNotSupported setting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14656/files - new: https://git.openjdk.org/jdk/pull/14656/files/639372ca..182f8c05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14656&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14656&range=02-03 Stats: 34 lines in 1 file changed: 5 ins; 24 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14656/head:pull/14656 PR: https://git.openjdk.org/jdk/pull/14656 From alanb at openjdk.org Wed Jun 28 19:46:28 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Jun 2023 19:46:28 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v3] In-Reply-To: References: <1RASu459l4EcM-xWfMGBRs_WP0iKjpLNSfF5t-tKwsA=.878e528b-555a-4668-88ba-7c7712ea913f@github.com> Message-ID: On Wed, 28 Jun 2023 19:07:14 GMT, Brian Burkhalter wrote: >> I'll check it but all I've really done here is rename fileSupported to transferToFileDirectNotSupported and inverted the values. > > In that case the situation did not change and whether it poses a problem could be investigated under another issue. I think the simplest thing is to remove fileSupported for now. Also if we limit the get/set of transferToDirectNotSupported to transferToDirect, and limit the get/set of transfeFromDirectNotSupported to transferFromDirect then it removes any confusion as to when the direct cases are disabled. I've done that now and updated the PR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14656#discussion_r1245683370 From bpb at openjdk.org Wed Jun 28 22:56:58 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Jun 2023 22:56:58 GMT Subject: RFR: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues [v4] In-Reply-To: <3G4_QQsJC7TOfs39NwRNU8hKmDC2zt--l5LMmuZjPW0=.b0c8d30e-275a-487d-9fba-7e5fcefe1538@github.com> References: <3G4_QQsJC7TOfs39NwRNU8hKmDC2zt--l5LMmuZjPW0=.b0c8d30e-275a-487d-9fba-7e5fcefe1538@github.com> Message-ID: On Wed, 28 Jun 2023 19:46:13 GMT, Alan Bateman wrote: >> This change fixes a number of bugs with FileChannel.transferTo/transerFrom that arise when the source or target channel is closed, or the thread is interrupted, during the transfer. More specifically: >> >> - The direct implementations operate on the raw file descriptor and don't prevent the target/source channel from being closed during the transfer. For this PR, the direct transferTo is limited to cases where the target is a FileChannel or SocketChannel. It could be extended to other SelChImpl implementations (SinkChannel, DatagramChannel) if needed, but they are less interesting at this time. >> >> - The transferTo/transferFrom methods are specified to throw ClosedByInterruptException after closing both channels. This is implemented inconsistently, and leaves one channel open in several cases. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup transferToDirectNotSupported/transferFromDirectNotSupported setting Last changes look good. Approved. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14656#pullrequestreview-1504322865 From alanb at openjdk.org Thu Jun 29 05:45:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jun 2023 05:45:09 GMT Subject: Integrated: 8310902: (fc) FileChannel.transferXXX async close and interrupt issues In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 17:14:15 GMT, Alan Bateman wrote: > This change fixes a number of bugs with FileChannel.transferTo/transerFrom that arise when the source or target channel is closed, or the thread is interrupted, during the transfer. More specifically: > > - The direct implementations operate on the raw file descriptor and don't prevent the target/source channel from being closed during the transfer. For this PR, the direct transferTo is limited to cases where the target is a FileChannel or SocketChannel. It could be extended to other SelChImpl implementations (SinkChannel, DatagramChannel) if needed, but they are less interesting at this time. > > - The transferTo/transferFrom methods are specified to throw ClosedByInterruptException after closing both channels. This is implemented inconsistently, and leaves one channel open in several cases. This pull request has now been integrated. Changeset: f4b900b6 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/f4b900b607b2e857a0177d1e3061fd4dfc6b5f75 Stats: 850 lines in 3 files changed: 656 ins; 85 del; 109 mod 8310902: (fc) FileChannel.transferXXX async close and interrupt issues Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/14656 From erikj at openjdk.org Thu Jun 29 07:23:54 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 29 Jun 2023 07:23:54 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14698#pullrequestreview-1504702261 From dholmes at openjdk.org Thu Jun 29 07:43:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jun 2023 07:43:58 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing. It also seems far too large and disruptive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612567676 From erikj at openjdk.org Thu Jun 29 08:00:58 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 29 Jun 2023 08:00:58 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes wrote: > This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing. The patch is leaving exactly one newline at the end of the file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612588091 From lkorinth at openjdk.org Thu Jun 29 08:58:59 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 08:58:59 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes wrote: > This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing. > > It also seems far too large and disruptive. Do you still think it is too disruptive after Erik's explanation? I could split it in more reviews, but I thought that maybe it would just make the review harder. I was hoping the two `git diff` commands I gave in my first comment in combination with the clean script would make the change seem reviewable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612660457 From coleenp at openjdk.org Thu Jun 29 12:03:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 29 Jun 2023 12:03:56 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change Why do we care about this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613018234 From dholmes at openjdk.org Thu Jun 29 12:14:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jun 2023 12:14:55 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com> On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end. But to me this is too disruptive with no tangible benefit. And you need buy-in from all the different areas affected by this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613043398 From lkorinth at openjdk.org Thu Jun 29 12:38:57 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 12:38:57 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 12:01:03 GMT, Coleen Phillimore wrote: > Why do we care about this? I care because of global-whitespace-cleanup-mode (in emacs). It helps me remove trailing whitespaces and blanklines when saving but it will not fix a file that was "dirty" when it was opened. Trailing blank lines triggers it not to clean whitespaces for me. And it does not look good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613095390 From coleenp at openjdk.org Thu Jun 29 12:42:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 29 Jun 2023 12:42:56 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change You could fix your emacs functions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613106245 From lkorinth at openjdk.org Thu Jun 29 13:08:59 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 13:08:59 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com> References: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com> Message-ID: On Thu, 29 Jun 2023 12:11:40 GMT, David Holmes wrote: > Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end. My changes look like this in the diff output } - Removal of the last newline would look like this: -} +} \ No newline at end of file (both with `git diff` and `git diff --unified`) I have not tested if this is also true for the generated webrevs, but I think that is precisely how they are created. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613152641 From lkorinth at openjdk.org Thu Jun 29 14:12:55 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 14:12:55 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 12:40:34 GMT, Coleen Phillimore wrote: > You could fix your emacs functions. It is a *very nice* feature of global-whitespace-cleanup-mode ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613252347 From coleenp at openjdk.org Thu Jun 29 15:46:57 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 29 Jun 2023 15:46:57 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change Per had an emacs feature to remove whitespaces at the end of the line, and gave me the vim version of that. That's a nice feature. I object to this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613437709 From lkorinth at openjdk.org Thu Jun 29 16:55:05 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 16:55:05 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change This was not liked, I will close it. I will possibly do it under another PR for the GC code. Thanks for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613526703 From lkorinth at openjdk.org Thu Jun 29 16:55:06 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 29 Jun 2023 16:55:06 GMT Subject: Withdrawn: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14698 From dholmes at openjdk.org Fri Jun 30 01:24:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jun 2023 01:24:05 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com> Message-ID: On Thu, 29 Jun 2023 13:05:58 GMT, Leo Korinth wrote: > My changes look like this in the diff output > ``` > } > - > ``` Thanks for showing this and other output. To me this looked like the final newline had been removed. I would have expected to see something that more obviously showed more than one blank line before hand and exactly one after. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613985636 From mbaesken at openjdk.org Fri Jun 30 14:19:54 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 30 Jun 2023 14:19:54 GMT Subject: RFR: JDK-8310734: Add cause to Connection reset - SocketException in NioSocketImpl implRead Message-ID: In NioSocketImpl implRead we potentially throw a SocketException("Connection reset"). We can improve this by adding the cause. This would bring this exception also closer to the case of IOException where we use throw asSocketException(ioe); and preserve the stack and message of the original exception. ------------- Commit messages: - JDK-8310734 Changes: https://git.openjdk.org/jdk/pull/14734/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14734&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310734 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14734/head:pull/14734 PR: https://git.openjdk.org/jdk/pull/14734 From dcubed at openjdk.org Fri Jun 30 15:21:10 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 30 Jun 2023 15:21:10 GMT Subject: RFR: 8311043: Remove trailing blank lines in source files In-Reply-To: References: Message-ID: <1HPsLLkrre-aTNkUCrJ2Os1Ba20NZW-s3bYL1nJU17Q=.47ea0d5b-f382-48a5-ba1b-957a003277d6@github.com> On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no changes > `git diff --ignore-blank-lines master` displays one change Ending the file with a blank line? I would not have expected that at all. I expect a single EOL at the end of the file; from a visual POV, the last line of non-blank text ends with an EOL. No more, no less. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1614806396