From github.com+1701815+mkarg at openjdk.java.net Thu Sep 2 07:49:28 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 2 Sep 2021 07:49:28 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v4] In-Reply-To: References: Message-ID: On Sun, 29 Aug 2021 16:24:01 GMT, Alan Bateman wrote: >> @bplb @AlanBateman As discussed before, I have changed the test in this PR to cover the following cases: >> * Testing random buffer sizes >> * Testing random initial source position >> * Testing random initial target position >> >> I deliberately did not test the following: >> * 2GB+: IMHO makes not much sense to add such a heavy weight test as the expected benefit will not really outweigh the test complexity needed, will slow down test performance massively, and was not tested in the original implementation / in https://github.com/openjdk/jdk/blob/master/test/jdk/java/io/FileInputStream/TransferTo.java, too. There is no rule that we have to provide 100% test coverage in OpenJDK. Actually adding a test must be well justified and is not the only measure we have in the box to prevent the occurance of bugs in production: I suggest, instead of a 2GB+ test, we agree that the contributed implementation *looks* correct to each of us (= applying six-eyes principle). For such a simple code line, this should be enough QA, as in case it unexpectedly would break, it is very likely to get reported by beta testers long before GA (possibly by myself as many of my projects move around 4GB+ sized files in reality), which should be early enough to catch and fix. >> * Same for testing position-after-transfer. This is not covered by the original test, and due to our six eyes it is highly unlikely that it is broken or will break in future. So I'd say KISS here. >> >> Wherever it made sense (without sacrifying my intended modularity needed for other channel types tested later) I tried to follow the solutions found in https://github.com/openjdk/jdk/blob/master/test/jdk/java/io/FileInputStream/TransferTo.java. Thanks Bran, for this blue print. In fact I wonder if the introduction of 10 loops over random sizes actually will improve test qualify. My assumption is that it rather reduces test stability and test repeatability: In case there actually is a bug that happens only with a specific combination of buffer size and initial positions, ten iterations will be much too few to stably reproduce the bug at each execution of the test. More often that not, that ten loops will all pass without running into the problem given the huge max size. This will driver testers nuts! The improved entropy by introducing the JDK randomizer does not help much to improve this. Having said that, I copied the solution from Brian only because he came up with it, and I can live with the statistical unpredictability it induces, but just wanted to clearly say that I (spoiler: working for a company providing QA tools like FMEA and SPC software) would say introducing random here induces more harm due to non-repeatability than it actualy improves the detection rate of failures not detected by thorough six-eye review. > >> * 2GB+: IMHO makes not much sense to add such a heavy weight test as the expected benefit will not really outweigh the test complexity needed, > > I'll try to get time to look at what you have in the next few days but just to say that the suggestion for exercising files > 2GB is because it's beyond the limit of the underlying sendfile. You should be able to check this quickly by printing the iteration count in ChannelInputStream.transferTo, it is always 1? @AlanBateman @bplb Would be cool if we could finish this PR this week, so if there are serious pain points that MUST get covered it would be great if you find the time to clearly point them out in the next days! Thanks! :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5209 From dfuchs at openjdk.java.net Thu Sep 2 14:29:24 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 2 Sep 2021 14:29:24 GMT Subject: RFR: 8238274: (sctp) JDK-7118373 is not fixed for SctpChannel In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 08:37:46 GMT, Masanori Yano wrote: > Please review this change to the Unix implementations of sun.nio.ch.sctp.Sctp*ChannelImpl#implCloseSelectableChannel() > to be same as SocketChannelImpl at JDK-7118373. (The preClose is missing a check for the ST_KILLED state.) I have run this change on one of our machines that support SCTP. I did get some intermittent failures with the other SCTP tests - they don't seem much stable - but the new proposed test was failing all the time. I suspect that using `lsof` to figure out whether the file descriptor was closed is not reliable/portable enough. I also tried to modify the test to use /othervm - which is probably a good idea if you don't want your results to be polluted by whatever other test might have run previously in the agent VM - but to no avail: the test was still failing 100% of the time. @masyano could you figure another way to detect whether the file descriptor has been released? ------------- PR: https://git.openjdk.java.net/jdk/pull/5274 From bpb at openjdk.java.net Fri Sep 3 01:01:47 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 3 Sep 2021 01:01:47 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v9] In-Reply-To: <8vwe-oQ5ilpMKuep4zSHycQisXMIFImfyE4hRVFvCS8=.c0fbf5b2-ccf3-46f4-bce1-6bb5fb3403e3@github.com> References: <8vwe-oQ5ilpMKuep4zSHycQisXMIFImfyE4hRVFvCS8=.c0fbf5b2-ccf3-46f4-bce1-6bb5fb3403e3@github.com> Message-ID: On Sat, 31 Jul 2021 00:59:19 GMT, Brian Burkhalter wrote: >> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`. >> >> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.) >> >> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension. >> >> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero. >> >> The behavior of the proposed method for some example cases is as: >> >> >> . -> >> .. -> >> .a.b -> b >> ...... -> >> .....a -> a >> ....a.b -> b >> ..foo -> foo >> test.rb -> rb >> a/b/d/test.rb -> rb >> .a/b/d/test.rb -> rb >> foo. -> >> test -> >> .profile -> >> .profile.sh -> sh >> ..foo -> foo >> .....foo -> foo >> .vimrc -> >> test. -> >> test.. -> >> test... -> >> foo.tar.gz -> gz >> foo.bar. -> >> image.jpg -> jpg >> music.mp3 -> mp3 >> video.mp4 -> mp4 >> document.txt -> txt >> foo.tar.gz -> gz >> foo.bar. -> > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - 8057113: Optimistically update @since tag to 18 > - Merge > - 8057113: Change first sentence; change param name > - 8057113: Change Path.getExtension() to accept a default return value in case the extension is indeterminate > - 8057113: Tweak spec again, and @implSpec code > - 8057113: Add @since tag > - 8057113: Tweak first sentence of spec > - 8057113: Handle getFileName() == null; revise spec > - 8057113: Changes pursuant to PR conversation > - 8057113: (fs) Path should have a method to obtain the filename extension PR extension. ------------- PR: https://git.openjdk.java.net/jdk/pull/2319 From msheppar at openjdk.java.net Fri Sep 3 20:39:26 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Fri, 3 Sep 2021 20:39:26 GMT Subject: RFR: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode Message-ID: A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. In some instances this is a receive call blocking indefinitely waiting on data which has already been sent, and should be available immediately to the receive method call. Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the ManySourcesAndTargets test has been amended to execute in othervm mode. Additionally, to assist in the buffer allocation issue, the netstat command executed by the test failure_handler has an extra argument added to obtain additional details on mbuf usage. The failure handler will now execute with netstat -mm ------------- Commit messages: - JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode Changes: https://git.openjdk.java.net/jdk/pull/5366/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5366&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273246 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5366.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5366/head:pull/5366 PR: https://git.openjdk.java.net/jdk/pull/5366 From alanb at openjdk.java.net Sat Sep 4 06:50:47 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 4 Sep 2021 06:50:47 GMT Subject: RFR: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 20:32:20 GMT, Mark Sheppard wrote: > A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. > In some instances this is a receive call blocking indefinitely waiting on data which has > already been sent, and should be available immediately to the receive method call. > Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: > "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" > > The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic > Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the > ManySourcesAndTargets test has been amended to execute in othervm mode. > > Additionally, to assist in the buffer allocation issue, the netstat command executed by the test > failure_handler has an extra argument added to obtain additional details on mbuf usage. > The failure handler will now execute with netstat -mm Marked as reviewed by alanb (Reviewer). test/jdk/java/nio/channels/DatagramChannel/ManySourcesAndTargets.java line 28: > 26: * @summary Test DatagramChannel send/receive and that receive returns the expected > 27: * sender address > 28: * @run main/othervm ManySourcesAndTargets This change looks okay. Do you mind change L143 to use sender.send rather than reader.send while you are there? That will avoid at least some questions while trying to track down the underlying issue and will ensure that the test is printing out the actual sender address. ------------- PR: https://git.openjdk.java.net/jdk/pull/5366 From msheppar at openjdk.java.net Sat Sep 4 09:27:47 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sat, 4 Sep 2021 09:27:47 GMT Subject: RFR: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode In-Reply-To: References: Message-ID: <_r2peYohEmXneKEiknkrV3GYcwcvg4rkY3M-7vaeDrE=.ae667cdc-3e55-4ad7-84e8-3e6112d11793@github.com> On Sat, 4 Sep 2021 06:47:43 GMT, Alan Bateman wrote: >> A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. >> In some instances this is a receive call blocking indefinitely waiting on data which has >> already been sent, and should be available immediately to the receive method call. >> Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: >> "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" >> >> The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic >> Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the >> ManySourcesAndTargets test has been amended to execute in othervm mode. >> >> Additionally, to assist in the buffer allocation issue, the netstat command executed by the test >> failure_handler has an extra argument added to obtain additional details on mbuf usage. >> The failure handler will now execute with netstat -mm > > test/jdk/java/nio/channels/DatagramChannel/ManySourcesAndTargets.java line 28: > >> 26: * @summary Test DatagramChannel send/receive and that receive returns the expected >> 27: * sender address >> 28: * @run main/othervm ManySourcesAndTargets > > This change looks okay. Do you mind change L143 to use sender.send rather than reader.send while you are there? That will avoid at least some questions while trying to track down the underlying issue and will ensure that the test is printing out the actual sender address. yes, I can do that ... the suggested change is currently part of a set of changes for JDK-8264385, but no problem to add it here now for this change set ------------- PR: https://git.openjdk.java.net/jdk/pull/5366 From msheppar at openjdk.java.net Sun Sep 5 11:00:27 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Sun, 5 Sep 2021 11:00:27 GMT Subject: RFR: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode [v2] In-Reply-To: References: Message-ID: > A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. > In some instances this is a receive call blocking indefinitely waiting on data which has > already been sent, and should be available immediately to the receive method call. > Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: > "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" > > The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic > Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the > ManySourcesAndTargets test has been amended to execute in othervm mode. > > Additionally, to assist in the buffer allocation issue, the netstat command executed by the test > failure_handler has an extra argument added to obtain additional details on mbuf usage. > The failure handler will now execute with netstat -mm Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision: JDK-8273246 fix logic error in testReceive method change reader.send to sender.send ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5366/files - new: https://git.openjdk.java.net/jdk/pull/5366/files/afe29d42..0effbcd4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5366&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5366&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5366.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5366/head:pull/5366 PR: https://git.openjdk.java.net/jdk/pull/5366 From alanb at openjdk.java.net Sun Sep 5 12:38:52 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 5 Sep 2021 12:38:52 GMT Subject: RFR: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode [v2] In-Reply-To: References: Message-ID: <9vwG8dx4p0bvGEZu9DRrXZmttjtWm-ACbo26a6-bJdM=.9dd6b4de-b095-4d9c-a9e0-adffb838f16e@github.com> On Sun, 5 Sep 2021 11:00:27 GMT, Mark Sheppard wrote: >> A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. >> In some instances this is a receive call blocking indefinitely waiting on data which has >> already been sent, and should be available immediately to the receive method call. >> Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: >> "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" >> >> The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic >> Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the >> ManySourcesAndTargets test has been amended to execute in othervm mode. >> >> Additionally, to assist in the buffer allocation issue, the netstat command executed by the test >> failure_handler has an extra argument added to obtain additional details on mbuf usage. >> The failure handler will now execute with netstat -mm > > Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8273246 fix logic error in testReceive method change reader.send to sender.send Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5366 From github.com+1701815+mkarg at openjdk.java.net Sun Sep 5 21:02:22 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 5 Sep 2021 21:02:22 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v9] In-Reply-To: References: Message-ID: > As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and https://github.com/openjdk/jdk/pull/5179 and deliberately concentrates **only** on the case where both, source **and** target, are actually `FileChannel`s. Other types of channels will be discussed in future PRs. > > * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. > > Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997). Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Testing source and target beyond EOF Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5209/files - new: https://git.openjdk.java.net/jdk/pull/5209/files/98dc61e5..852032d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5209&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5209&range=07-08 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5209/head:pull/5209 PR: https://git.openjdk.java.net/jdk/pull/5209 From github.com+1701815+mkarg at openjdk.java.net Mon Sep 6 06:38:11 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Mon, 6 Sep 2021 06:38:11 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v10] In-Reply-To: References: Message-ID: > As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and https://github.com/openjdk/jdk/pull/5179 and deliberately concentrates **only** on the case where both, source **and** target, are actually `FileChannel`s. Other types of channels will be discussed in future PRs. > > * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. > > Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997). Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Renamed contents() to testStreamContents() Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5209/files - new: https://git.openjdk.java.net/jdk/pull/5209/files/852032d9..6b4c34c7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5209&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5209&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5209/head:pull/5209 PR: https://git.openjdk.java.net/jdk/pull/5209 From github.com+1701815+mkarg at openjdk.java.net Mon Sep 6 10:08:28 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Mon, 6 Sep 2021 10:08:28 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v12] In-Reply-To: References: Message-ID: > As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and https://github.com/openjdk/jdk/pull/5179 and deliberately concentrates **only** on the case where both, source **and** target, are actually `FileChannel`s. Other types of channels will be discussed in future PRs. > > * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. > > Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997). Markus KARG has updated the pull request incrementally with five additional commits since the last revision: - Replaced 'point' by 'position' in comments Signed-off-by: Markus Karg - Moved TransferTo.java from test/jdk/sun/nio/ch/ChannelInputStream/ to test/jdk/java/nio/channels/Channels/ Signed-off-by: Markus Karg - Redeced line lenght; maximum length now is 115 characters Signed-off-by: Markus Karg - Removed static modifiers on interfaces Signed-off-by: Markus Karg - Removed unused imports Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5209/files - new: https://git.openjdk.java.net/jdk/pull/5209/files/90a176f3..cb2a8636 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5209&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5209&range=10-11 Stats: 15 lines in 1 file changed: 0 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5209/head:pull/5209 PR: https://git.openjdk.java.net/jdk/pull/5209 From github.com+1701815+mkarg at openjdk.java.net Mon Sep 6 11:47:45 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Mon, 6 Sep 2021 11:47:45 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v4] In-Reply-To: References: Message-ID: On Sun, 29 Aug 2021 16:24:01 GMT, Alan Bateman wrote: > The src/ implementation changes are fine, I think we agreed those previously. Agreed. > It would be cleaner if this test had been created as TestNG test. That would allow us to get rid of Thrower and the assertThrowsXXX infrastructure. It would allow us to use data providers too. Maybe it can be converted and cleaned up in a future PR. I confirm that I will migrate to TestNG in a future PR. > I think I mentioned this previously but the test can go into test/jdk/java/nio/channels/Channels so that it's in the same directory as the other tests for the Channels API/implementation. Done in https://github.com/openjdk/jdk/pull/5209/commits/c886fbc26e18262539473bd66f091083fe9b7fbf. > ifOutIsNullThenNpeIsThrown is a strange method name, can we rename it to something testNullPointerException or something more obvious? Done in https://github.com/openjdk/jdk/pull/5209/commits/90a176f346d65782b703f194197c6858bce1077b. > "contents" is also a bit strange for the method name. This where the real test is so let's rename that to something more obvious too. Done in https://github.com/openjdk/jdk/pull/5209/commits/6b4c34c707778c68d3b06cc401c8c175918a60ea. >There's a typo in one of the comments here it says "starting point", should be "starting position". Done in https://github.com/openjdk/jdk/pull/5209/commits/cb2a863665f3fb329bd9c9237fc634a046d2edf1. > You've got reasonable coverage for random initial positions in both source and target files, good! One other case that could be tested is where the initial position is beyond EOF. If the initial position of the source file is beyond EOF then 0 bytes will be transferred. If the initial position of the target file is beyond EOF then it will be extended. Done in https://github.com/openjdk/jdk/pull/5209/commits/852032d9bbe102ebec1b03de21492221003180cd. >At some point we should look at adding a test for files > 2Gb as otherwise we aren't testing the loop (as we discussed). Agreed that *at some point* (i. e. in *some* future PR) someone could provide such a test. As explained in https://github.com/openjdk/jdk/pull/5209#issuecomment-907782217 there is no 100% path coverage rule in OpenJDK, so while this *might* be a good idea, it seems it is definitively not a *mandatory* constraint to test that loop at all. > A few minor nits: The copyright date says "2014", I assume copied from another test. It actually reads "2014, 2021" which means that the original code was first published in 2014 and was last modified in 2021. Oracle once asked me to always do it *exactly that way* when touching any Oracle source code (which I did here, as the test originated from existing Oracle source code). If OpenJDK is an exceptional case here, then please confirm that I am *officially allowed* to remove the year 2014 from that list. Until then I have to keep the line exactly the way it is to not get into any troubles with Oracle's legal department. > There are several unused imports to remove. Done in https://github.com/openjdk/jdk/pull/5209/commits/c3dbc33880ebea4b11f014c6c0046f3d5cc24e1e. >The static modifiers on interfaces aren't needed. Done in https://github.com/openjdk/jdk/pull/5209/commits/f3a6551d009d2a22d6d2aa448025330623c64065. >There are few really long lines, one is 150+ that wraps and will be annoying for side-by-side diffs when changed in the future. Done in https://github.com/openjdk/jdk/pull/5209/commits/412fab109c94de21a19cdc6a8aa3060e41deeb51. The longest code line now is 115 characters which should be fine for side-by-side views as my screen shows more than 250 characters per line. I hope that with my recent changes this PR now is in a shape which allows it to get merged. As we agreed on multiple small PRs instead of a single big one, our target should be to contain only the *essential changes per each PR* but add *more PRs ontop* for non-essential improvements (which I will be happy to provide). ------------- PR: https://git.openjdk.java.net/jdk/pull/5209 From alanb at openjdk.java.net Tue Sep 7 07:52:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 7 Sep 2021 07:52:41 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v12] In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 10:08:28 GMT, Markus KARG wrote: >> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and https://github.com/openjdk/jdk/pull/5179 and deliberately concentrates **only** on the case where both, source **and** target, are actually `FileChannel`s. Other types of channels will be discussed in future PRs. >> >> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. >> >> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997). > > Markus KARG has updated the pull request incrementally with five additional commits since the last revision: > > - Replaced 'point' by 'position' in comments > > Signed-off-by: Markus Karg > - Moved TransferTo.java from test/jdk/sun/nio/ch/ChannelInputStream/ to test/jdk/java/nio/channels/Channels/ > > Signed-off-by: Markus Karg > - Redeced line lenght; maximum length now is 115 characters > > Signed-off-by: Markus Karg > - Removed static modifiers on interfaces > > Signed-off-by: Markus Karg > - Removed unused imports > > Signed-off-by: Markus Karg > Agreed that _at some point_ (i. e. in _some_ future PR) someone could provide such a test. As explained in [#5209 (comment)](https://github.com/openjdk/jdk/pull/5209#issuecomment-907782217) there is no 100% path coverage rule in OpenJDK, so while this _might_ be a good idea, it seems it is definitively not a _mandatory_ constraint to test that loop at all. The override of InputStream::transferTo is calling FileChannel::transferTo in a loop so I don't think it is unreasonable to ask if we have test that has more than one iteration. I'm okay if we defer this to a further step but I do think we should have test for this case. > It actually reads "2014, 2021" which means that the original code was first published in 2014 and was last modified in 2021. Oracle once asked me to always do it _exactly that way_ when touching any Oracle source code (which I did here, as the test originated from existing Oracle source code). If OpenJDK is an exceptional case here, then please confirm that I am _officially allowed_ to remove the year 2014 from that list. Until then I have to keep the line exactly the way it is to not get into any troubles with Oracle's legal department. This is a new test, the date should be 2021. ------------- PR: https://git.openjdk.java.net/jdk/pull/5209 From github.com+1701815+mkarg at openjdk.java.net Tue Sep 7 11:44:13 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Tue, 7 Sep 2021 11:44:13 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v13] In-Reply-To: References: Message-ID: > As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and https://github.com/openjdk/jdk/pull/5179 and deliberately concentrates **only** on the case where both, source **and** target, are actually `FileChannel`s. Other types of channels will be discussed in future PRs. > > * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. > > Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997). Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Copyright (C) 2021 instead of 2014, 2021 Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5209/files - new: https://git.openjdk.java.net/jdk/pull/5209/files/cb2a8636..1804aa00 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5209&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5209&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5209/head:pull/5209 PR: https://git.openjdk.java.net/jdk/pull/5209 From github.com+1701815+mkarg at openjdk.java.net Tue Sep 7 11:46:37 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Tue, 7 Sep 2021 11:46:37 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v12] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 07:49:22 GMT, Alan Bateman wrote: > The override of InputStream::transferTo is calling FileChannel::transferTo in a loop so I don't think it is unreasonable to ask if we have test that has more than one iteration. I'm okay if we defer this to a further step but I do think we should have test for this case. I will look into testing the 2 GB+ iterations after this PR is merged and I'm done with my TestNG PR. > > It actually reads "2014, 2021" which means that the original code was first published in 2014 and was last modified in 2021. Oracle once asked me to always do it _exactly that way_ when touching any Oracle source code (which I did here, as the test originated from existing Oracle source code). If OpenJDK is an exceptional case here, then please confirm that I am _officially allowed_ to remove the year 2014 from that list. Until then I have to keep the line exactly the way it is to not get into any troubles with Oracle's legal department. > This is a new test, the date should be 2021. Done with https://github.com/openjdk/jdk/pull/5209/commits/1804aa00f34010a174301ac3d816de23806e179f. So this PR is fine for merging now? :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5209 From alanb at openjdk.java.net Tue Sep 7 13:26:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 7 Sep 2021 13:26:40 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v13] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 11:44:13 GMT, Markus KARG wrote: >> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and https://github.com/openjdk/jdk/pull/5179 and deliberately concentrates **only** on the case where both, source **and** target, are actually `FileChannel`s. Other types of channels will be discussed in future PRs. >> >> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. >> >> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997). > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Copyright (C) 2021 instead of 2014, 2021 > > Signed-off-by: Markus Karg > Done with [1804aa0](https://github.com/openjdk/jdk/commit/1804aa00f34010a174301ac3d816de23806e179f). Nearly there, it needs to be "2021," to avoid falling foul of scripts that check headers. ------------- PR: https://git.openjdk.java.net/jdk/pull/5209 From github.com+1701815+mkarg at openjdk.java.net Tue Sep 7 13:42:09 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Tue, 7 Sep 2021 13:42:09 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v14] In-Reply-To: References: Message-ID: > As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and https://github.com/openjdk/jdk/pull/5179 and deliberately concentrates **only** on the case where both, source **and** target, are actually `FileChannel`s. Other types of channels will be discussed in future PRs. > > * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. > > Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997). Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Added comma after year in copyright Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5209/files - new: https://git.openjdk.java.net/jdk/pull/5209/files/1804aa00..1f5a4567 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5209&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5209&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5209/head:pull/5209 PR: https://git.openjdk.java.net/jdk/pull/5209 From github.com+1701815+mkarg at openjdk.java.net Tue Sep 7 13:42:11 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Tue, 7 Sep 2021 13:42:11 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v13] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 13:23:18 GMT, Alan Bateman wrote: > > Done with [1804aa0](https://github.com/openjdk/jdk/commit/1804aa00f34010a174301ac3d816de23806e179f). > Nearly there, it needs to be "2021," to avoid falling foul of scripts that check headers. Done with https://github.com/openjdk/jdk/pull/5209/commits/1f5a4567e3eaf55bf82f97164fb97c2abba481c8. ------------- PR: https://git.openjdk.java.net/jdk/pull/5209 From github.com+1701815+mkarg at openjdk.java.net Tue Sep 7 16:05:09 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Tue, 7 Sep 2021 16:05:09 GMT Subject: RFR: 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo() [v10] In-Reply-To: References: Message-ID: > As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and deliberately concentrates **only** on `FileChannel`s. Other types of channels will be discussed in future PRs. > > * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. > > Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997). Markus KARG has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 11 new commits since the last revision: - 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo(WritableByteChannel) As suggested in 8265891 this change implements a performance optimization for ChannelInputStream.transferTo(): It uses FileChannel.transferTo(WritableByteChannel) in case the source channel actually is a FileChannel and the target channel is a WritableByteChannel, as in that case, the actual work of transferring bytes can potentially get offloaded to the operating system / file system. Signed-off-by: Markus Karg - Added comma after year in copyright Signed-off-by: Markus Karg - Copyright (C) 2021 instead of 2014, 2021 Signed-off-by: Markus Karg - Replaced 'point' by 'position' in comments Signed-off-by: Markus Karg - Moved TransferTo.java from test/jdk/sun/nio/ch/ChannelInputStream/ to test/jdk/java/nio/channels/Channels/ Signed-off-by: Markus Karg - Redeced line lenght; maximum length now is 115 characters Signed-off-by: Markus Karg - Removed static modifiers on interfaces Signed-off-by: Markus Karg - Removed unused imports Signed-off-by: Markus Karg - Renamed ifOutIsNullThenNpeIsThrows to testNullPointerException Signed-off-by: Markus Karg - Renamed contents() to testStreamContents() Signed-off-by: Markus Karg - ... and 1 more: https://git.openjdk.java.net/jdk/compare/a507fd77...e76caa46 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5179/files - new: https://git.openjdk.java.net/jdk/pull/5179/files/a507fd77..e76caa46 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5179&range=08-09 Stats: 28 lines in 1 file changed: 7 ins; 10 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5179/head:pull/5179 PR: https://git.openjdk.java.net/jdk/pull/5179 From msheppar at openjdk.java.net Tue Sep 7 22:21:14 2021 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Tue, 7 Sep 2021 22:21:14 GMT Subject: Integrated: JDK-8273246 Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 20:32:20 GMT, Mark Sheppard wrote: > A number of nio DatagramChannel tests are intermittently failing on macosx-aarch64. > In some instances this is a receive call blocking indefinitely waiting on data which has > already been sent, and should be available immediately to the receive method call. > Other test failure scenarios are problems during the test compilation phase with a SocketException being thrown and the message: > "test result: Error. Agent communication error: java.net.SocketException: No buffer space available; check console log for any additional details" > > The ManySourcesAndTargets and other tests execute in agentvm mode. This results in certain test diagnostic > Output being lost during the test failure handling capture process. To mitigate this lost diagnostics, the > ManySourcesAndTargets test has been amended to execute in othervm mode. > > Additionally, to assist in the buffer allocation issue, the netstat command executed by the test > failure_handler has an extra argument added to obtain additional details on mbuf usage. > The failure handler will now execute with netstat -mm This pull request has now been integrated. Changeset: d6d6c069 Author: Mark Sheppard URL: https://git.openjdk.java.net/jdk/commit/d6d6c0692bff77bd18127ed61455aac39370a089 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8273246: Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5366 From alanb at openjdk.java.net Wed Sep 8 09:17:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 8 Sep 2021 09:17:09 GMT Subject: RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v14] In-Reply-To: References: Message-ID: <1Z59AeL5l919tZ9mAiR9NB1UC9RcGBavJUbHOZJkk7g=.f82d9158-51f5-4483-ad02-4fd1e91221e3@github.com> On Tue, 7 Sep 2021 13:42:09 GMT, Markus KARG wrote: >> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and https://github.com/openjdk/jdk/pull/5179 and deliberately concentrates **only** on the case where both, source **and** target, are actually `FileChannel`s. Other types of channels will be discussed in future PRs. >> >> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. >> >> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997). > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Added comma after year in copyright > > Signed-off-by: Markus Karg I've tested the patch against the current main line (the PR is against a repo that is 4 or 5 months behind the main line). All okay. The expectation is that the test will be improved and iterated on in subsequent PRs. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5209 From github.com+1701815+mkarg at openjdk.java.net Wed Sep 8 11:25:25 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Wed, 8 Sep 2021 11:25:25 GMT Subject: Integrated: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) In-Reply-To: References: Message-ID: <8OrIS7EpMV6yDmDevGJuI2uQJ6znzRasqGBBlkSAdTk=.587c5d94-037f-4632-9be6-8a02eb74181b@github.com> On Sat, 21 Aug 2021 14:33:43 GMT, Markus KARG wrote: > As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and https://github.com/openjdk/jdk/pull/5179 and deliberately concentrates **only** on the case where both, source **and** target, are actually `FileChannel`s. Other types of channels will be discussed in future PRs. > > * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. > > Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997). This pull request has now been integrated. Changeset: 18555742 Author: Markus Karg Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/185557423d3069d627daecdf87315a49d6597b67 Stats: 464 lines in 4 files changed: 384 ins; 76 del; 4 mod 8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5209 From github.com+1701815+mkarg at openjdk.java.net Wed Sep 8 17:26:17 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Wed, 8 Sep 2021 17:26:17 GMT Subject: RFR: 8273507: Using TestNG for unit testing ChannelInputStream::transferTo Message-ID: Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* ------------- Commit messages: - Migrated to TestNG Changes: https://git.openjdk.java.net/jdk/pull/5421/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273507 Stats: 61 lines in 1 file changed: 10 ins; 32 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5421/head:pull/5421 PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Wed Sep 8 17:26:17 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Wed, 8 Sep 2021 17:26:17 GMT Subject: RFR: 8273507: Using TestNG for unit testing ChannelInputStream::transferTo In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 17:17:32 GMT, Markus KARG wrote: > Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. > > This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. > > *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* @AlanBateman @blbp As announced and requested, here is the migration to TestNG. Kindly requesting your review. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From lancea at openjdk.java.net Wed Sep 8 18:56:08 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 8 Sep 2021 18:56:08 GMT Subject: RFR: 8273507: Using TestNG for unit testing ChannelInputStream::transferTo In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 17:17:32 GMT, Markus KARG wrote: > Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. > > This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. > > *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* Look better overall. I would add a comment for for each DataProvider/Test to give future maintainers an overview of the intent of the methods A couple of additional comments below Best Lance test/jdk/java/nio/channels/Channels/TransferTo.java line 75: > 73: } > 74: > 75: @Test(dataProvider = "streamCombinations", expectedExceptions = NullPointerException.class) We have been moving away from using the expectedExceptions annotation element and using the assertThrows method instead, example: assertThrows(NullPointerException.class, () -> inputStreamProvider.input().transferTo(null)); test/jdk/java/nio/channels/Channels/TransferTo.java line 135: > 133: > 134: if (reported != count) > 135: fail(format("reported %d bytes but should report %d", reported, count)); I would consider using assertTrue( reported == count, format("reported %d bytes but should report %d", reported, count)); ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Thu Sep 9 06:26:29 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 9 Sep 2021 06:26:29 GMT Subject: RFR: 8273507: Using TestNG for unit testing ChannelInputStream::transferTo [v2] In-Reply-To: References: Message-ID: > Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. > > This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. > > *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Using assert* methods instead of fail() and expectedExceptions Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5421/files - new: https://git.openjdk.java.net/jdk/pull/5421/files/1d08b967..b37ad6b3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=00-01 Stats: 24 lines in 1 file changed: 4 ins; 13 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5421/head:pull/5421 PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Thu Sep 9 06:26:34 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 9 Sep 2021 06:26:34 GMT Subject: RFR: 8273507: Using TestNG for unit testing ChannelInputStream::transferTo [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 18:45:02 GMT, Lance Andersen wrote: >> Markus KARG has updated the pull request incrementally with one additional commit since the last revision: >> >> Using assert* methods instead of fail() and expectedExceptions >> >> Signed-off-by: Markus Karg > > test/jdk/java/nio/channels/Channels/TransferTo.java line 75: > >> 73: } >> 74: >> 75: @Test(dataProvider = "streamCombinations", expectedExceptions = NullPointerException.class) > > We have been moving away from using the expectedExceptions annotation element and using the assertThrows method instead, example: > > assertThrows(NullPointerException.class, () -> inputStreamProvider.input().transferTo(null)); Done in https://github.com/openjdk/jdk/pull/5421/commits/b37ad6b39ffc78af7ca8c487125b7e4e0c1ff141. > test/jdk/java/nio/channels/Channels/TransferTo.java line 135: > >> 133: >> 134: if (reported != count) >> 135: fail(format("reported %d bytes but should report %d", reported, count)); > > I would consider using > > assertTrue( reported == count, format("reported %d bytes but should report %d", reported, count)); Done in https://github.com/openjdk/jdk/pull/5421/commits/b37ad6b39ffc78af7ca8c487125b7e4e0c1ff141. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Thu Sep 9 07:11:58 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 9 Sep 2021 07:11:58 GMT Subject: RFR: 8273507: Using TestNG for unit testing ChannelInputStream::transferTo [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 18:53:06 GMT, Lance Andersen wrote: > I would add a comment for for each DataProvider/Test to give future maintainers an overview of the intent of the methods I support the general idea of making things more comprehensible, but I will abstain from adding comments in *this* PR due to three reasons: * This PR *solely* has the target of technically introducing **TestNG** and I really do not want to mix concerns like technical merits with documental merits. * The current PR is a blocker in the *critical path* of other, higher prioritized PRs. We should try not to slow it down *unnecessarily*. * I dislike code comments and would instead prefer to turn this source code into **BDD** style, i. e. changing the test name into "shouldDoThisInThatCase" style and introducing "given", "when" and "then" sections inside the tests. As this source code is a copy of two other original files, I will do it for all three files in one shot to keep their inherent relationship. So in the best sense of KISS, SoC and "release early, release often", it makes sense that I will create an (or mutiple) explicit, subsequent PR(s) for introducing BDD instead of adding code comments in the current (slow and big) PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From lancea at openjdk.java.net Thu Sep 9 14:16:04 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 9 Sep 2021 14:16:04 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 06:26:29 GMT, Markus KARG wrote: >> Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. >> >> This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. >> >> *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Using assert* methods instead of fail() and expectedExceptions > > Signed-off-by: Markus Karg > > I would add a comment for for each DataProvider/Test to give future maintainers an overview of the intent of the methods > > I support the general idea of making things more comprehensible, but I will abstain from adding comments in _this_ PR due to three reasons: > > * This PR _solely_ has the target of technically introducing **TestNG** and I really do not want to mix concerns like technical merits with documental merits. > * The current PR is a blocker in the _critical path_ of other, higher prioritized PRs. We should try not to slow it down _unnecessarily_. > * I dislike code comments and would instead prefer to turn this source code into **BDD** style, i. e. changing the test name into "shouldDoThisInThatCase" style and introducing "given", "when" and "then" sections inside the tests. As this source code is a copy of two other original files, I will do it for all three files in one shot to keep their inherent relationship. > > So in the best sense of KISS, SoC and "release early, release often", it makes sense that I will create an (or mutiple) explicit, subsequent PR(s) for introducing BDD instead of adding code comments in the current (slow and big) PR. We are going to have to agree to disagree here. Comments are/should be part of the development process including for tests. There is no reason to create additional issues or new PRs given the tests is already being modified. > > I would add a comment for for each DataProvider/Test to give future maintainers an overview of the intent of the methods > > I support the general idea of making things more comprehensible, but I will abstain from adding comments in _this_ PR due to three reasons: > > * This PR _solely_ has the target of technically introducing **TestNG** and I really do not want to mix concerns like technical merits with documental merits. > * The current PR is a blocker in the _critical path_ of other, higher prioritized PRs. We should try not to slow it down _unnecessarily_. > * I dislike code comments and would instead prefer to turn this source code into **BDD** style, i. e. changing the test name into "shouldDoThisInThatCase" style and introducing "given", "when" and "then" sections inside the tests. As this source code is a copy of two other original files, I will do it for all three files in one shot to keep their inherent relationship. > > So in the best sense of KISS, SoC and "release early, release often", it makes sense that I will create an (or mutiple) explicit, subsequent PR(s) for introducing BDD instead of adding code comments in the current (slow and big) PR. We are going to agree to disagree on this. There is no reason to create additional issues/PRs for improving the readability/documentation. Comments do not have to be extensive but enough to introduce the intent of the test. Now is the right time to add comments given the test is being updated. As we evolve/maintain OpenJDK, we want to keep maintainability for current and future developers in mind. Adding documentation/comments while we are updating/adding to the project will help in this endeavor (and I know it would have helped me while navigating areas of the codebase I was less familiar with). ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Fri Sep 10 06:29:05 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Fri, 10 Sep 2021 06:29:05 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 14:13:14 GMT, Lance Andersen wrote: > > > I would add a comment for for each DataProvider/Test to give future maintainers an overview of the intent of the methods > > > > > > I support the general idea of making things more comprehensible, but I will abstain from adding comments in _this_ PR due to three reasons: > > > > * This PR _solely_ has the target of technically introducing **TestNG** and I really do not want to mix concerns like technical merits with documental merits. > > * The current PR is a blocker in the _critical path_ of other, higher prioritized PRs. We should try not to slow it down _unnecessarily_. > > * I dislike code comments and would instead prefer to turn this source code into **BDD** style, i. e. changing the test name into "shouldDoThisInThatCase" style and introducing "given", "when" and "then" sections inside the tests. As this source code is a copy of two other original files, I will do it for all three files in one shot to keep their inherent relationship. > > > > So in the best sense of KISS, SoC and "release early, release often", it makes sense that I will create an (or mutiple) explicit, subsequent PR(s) for introducing BDD instead of adding code comments in the current (slow and big) PR. > > We are going to have to agree to disagree here. Comments are/should be part of the development process including for tests. There is no reason to create additional issues or new PRs given the tests is already being modified. > > > > I would add a comment for for each DataProvider/Test to give future maintainers an overview of the intent of the methods > > > > > > I support the general idea of making things more comprehensible, but I will abstain from adding comments in _this_ PR due to three reasons: > > > > * This PR _solely_ has the target of technically introducing **TestNG** and I really do not want to mix concerns like technical merits with documental merits. > > * The current PR is a blocker in the _critical path_ of other, higher prioritized PRs. We should try not to slow it down _unnecessarily_. > > * I dislike code comments and would instead prefer to turn this source code into **BDD** style, i. e. changing the test name into "shouldDoThisInThatCase" style and introducing "given", "when" and "then" sections inside the tests. As this source code is a copy of two other original files, I will do it for all three files in one shot to keep their inherent relationship. > > > > So in the best sense of KISS, SoC and "release early, release often", it makes sense that I will create an (or mutiple) explicit, subsequent PR(s) for introducing BDD instead of adding code comments in the current (slow and big) PR. > > We are going to agree to disagree on this. There is no reason to create additional issues/PRs for improving the readability/documentation. Comments do not have to be extensive but enough to introduce the intent of the test. Now is the right time to add comments given the test is being updated. > > As we evolve/maintain OpenJDK, we want to keep maintainability for current and future developers in mind. Adding documentation/comments while we are updating/adding to the project will help in this endeavor (and I know it would have helped me while navigating areas of the codebase I was less familiar with). So this effectively means that you rather want to *prevent* this PR, which was demanded by @AlanBateman, and rather want to live with the test *as-is*, unless I add more comments that are *totally unrelated* with this PR? So what if I just don't agree here? Then you will never get *either* the comments *nor* will Alan get TestNG. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Sat Sep 11 07:09:42 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sat, 11 Sep 2021 07:09:42 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 06:26:29 GMT, Markus KARG wrote: >> Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. >> >> This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. >> >> *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Using assert* methods instead of fail() and expectedExceptions > > Signed-off-by: Markus Karg @AlanBateman Would be great if you could accept this PR soon, as it contains the TestNG migration requested by you, and it blocks my chain of subsequent PRs for more transferTo() improvements. Thanks! :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From shade at openjdk.java.net Mon Sep 13 08:54:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 13 Sep 2021 08:54:48 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 06:26:29 GMT, Markus KARG wrote: >> Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. >> >> This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. >> >> *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Using assert* methods instead of fail() and expectedExceptions > > Signed-off-by: Markus Karg I think this PR is fine as it is. Additional documentation can be added in the separate PR. Maybe I am missing some subtleties here, by I find the test code pretty self-explanatory. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5421 From alanb at openjdk.java.net Mon Sep 13 09:12:49 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 13 Sep 2021 09:12:49 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v2] In-Reply-To: References: Message-ID: <9XPO9YcAPkKHDMDdoUGrizIaHcrmLRa-TBoyMJemES8=.2410586d-c80d-46a0-a525-746ab864f234@github.com> On Fri, 10 Sep 2021 06:26:26 GMT, Markus KARG wrote: > * I dislike code comments and would instead prefer to turn this source code into **BDD** style, i. e. changing the test name into "shouldDoThisInThatCase" style and introducing "given", "when" and "then" sections inside the tests. As this source code is a copy of two other original files, I will do it for all three files in one shot to keep their inherent relationship. Ugh, please no. As Lance said, we need the source and tests to be as easy to maintain as possible. In this case it would be helpful to have comments on testStreamContents and checkTransferredContents so that it's very quick for someone to know what the test is trying to when it fails (in this area, most of the effort on tests is spent chasing intermittent test failures). ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From bpb at openjdk.java.net Mon Sep 13 20:50:23 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 13 Sep 2021 20:50:23 GMT Subject: RFR: 8273641: (bf) Buffer subclasses documentation contains template strings Message-ID: Please consider this doc-only fix. The template processor apparently does not like the HTML space entity ` `. ------------- Commit messages: - 8273641: (bf) Buffer subclasses documentation contains template strings Changes: https://git.openjdk.java.net/jdk/pull/5502/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5502&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273641 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5502.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5502/head:pull/5502 PR: https://git.openjdk.java.net/jdk/pull/5502 From bpb at openjdk.java.net Mon Sep 13 20:50:24 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 13 Sep 2021 20:50:24 GMT Subject: RFR: 8273641: (bf) Buffer subclasses documentation contains template strings In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 20:36:30 GMT, Brian Burkhalter wrote: > Please consider this doc-only fix. The template processor apparently does not like the HTML space entity ` `. In passing some superfluous `and`s were removed from the unordered list of operation categories. ------------- PR: https://git.openjdk.java.net/jdk/pull/5502 From rriggs at openjdk.java.net Mon Sep 13 21:45:19 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 13 Sep 2021 21:45:19 GMT Subject: RFR: 8273641: (bf) Buffer subclasses documentation contains template strings In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 20:36:30 GMT, Brian Burkhalter wrote: > Please consider this doc-only fix. The template processor apparently does not like the HTML space entity ` `. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5502 From alanb at openjdk.java.net Tue Sep 14 06:39:03 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 14 Sep 2021 06:39:03 GMT Subject: RFR: 8273641: (bf) Buffer subclasses documentation contains template strings In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 20:36:30 GMT, Brian Burkhalter wrote: > Please consider this doc-only fix. The template processor apparently does not like the HTML space entity ` `. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5502 From bpb at openjdk.java.net Tue Sep 14 19:17:12 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 14 Sep 2021 19:17:12 GMT Subject: Integrated: 8273641: (bf) Buffer subclasses documentation contains template strings In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 20:36:30 GMT, Brian Burkhalter wrote: > Please consider this doc-only fix. The template processor apparently does not like the HTML space entity ` `. This pull request has now been integrated. Changeset: e7ab3724 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/e7ab3724e79312cf76c7a8fa6befc92e9c960607 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8273641: (bf) Buffer subclasses documentation contains template strings Reviewed-by: rriggs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5502 From github.com+1701815+mkarg at openjdk.java.net Wed Sep 15 06:01:47 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Wed, 15 Sep 2021 06:01:47 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v2] In-Reply-To: <9XPO9YcAPkKHDMDdoUGrizIaHcrmLRa-TBoyMJemES8=.2410586d-c80d-46a0-a525-746ab864f234@github.com> References: <9XPO9YcAPkKHDMDdoUGrizIaHcrmLRa-TBoyMJemES8=.2410586d-c80d-46a0-a525-746ab864f234@github.com> Message-ID: On Mon, 13 Sep 2021 09:10:13 GMT, Alan Bateman wrote: > Ugh, please no. As Lance said, we need the source and tests to be as easy to maintain as possible. In this case it would be helpful to have comments on testStreamContents and checkTransferredContents so that it's very quick for someone to know what the test is trying to when it fails (in this area, most of the effort on tests is spent chasing intermittent test failures). But that is **exactly** what BDD is good for, so I do not understand why you say "Ugh, please no."?! As Aleksey wrote he had no problems understanding the tests, so frankly spoken, I don't know **what** to write in the comments as it all looks pretty self-explanatory to me. I'm fine with adding your prefered wordings if you just type them into the comments. Unfortunately I cannot take [Brian's code](https://github.com/bplb/jdk/blob/3e575ba2f8d631e48cc50ca44898844790dd1ea7/test/jdk/java/io/FileInputStream/TransferTo.java) as a blue print here, as nobody asked for tests *there* so it simply says `test` which is more or less non-explanatory at all (and, BTW, I do not understand why *his* test shall be any simpler to maintain than mine to get a clue **what** you want me to actually document). ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From jboes at openjdk.java.net Wed Sep 15 08:57:55 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 15 Sep 2021 08:57:55 GMT Subject: RFR: 8273655: content-types.properties files are missing some common types Message-ID: This change adds some common types to the content-type.properties files, notably .js, .css, and .jar, as well as some others. The duplicated entry for .zip is removed from the Windows properties file. ------------- Commit messages: - add basic test - initial change Changes: https://git.openjdk.java.net/jdk/pull/5506/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5506&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273655 Stats: 171 lines in 3 files changed: 155 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5506.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5506/head:pull/5506 PR: https://git.openjdk.java.net/jdk/pull/5506 From ecki at zusammenkunft.net Wed Sep 15 09:40:50 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 15 Sep 2021 09:40:50 +0000 Subject: RFR: 8273655: content-types.properties files are missing some common types In-Reply-To: References: Message-ID: In the Test List .xml is not mentioned, that looks like a major format. However I am not sure if it maybe needs extra handling because of possible different mime types for application/xml and text/xml? -- http://bernd.eckenfels.net ________________________________ Von: net-dev im Auftrag von Julia Boes Gesendet: Wednesday, September 15, 2021 10:57:55 AM An: net-dev at openjdk.java.net ; nio-dev at openjdk.java.net Betreff: RFR: 8273655: content-types.properties files are missing some common types This change adds some common types to the content-type.properties files, notably .js, .css, and .jar, as well as some others. The duplicated entry for .zip is removed from the Windows properties file. ------------- Commit messages: - add basic test - initial change Changes: https://git.openjdk.java.net/jdk/pull/5506/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5506&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273655 Stats: 171 lines in 3 files changed: 155 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5506.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5506/head:pull/5506 PR: https://git.openjdk.java.net/jdk/pull/5506 -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+15714253+anthonyvdotbe at openjdk.java.net Wed Sep 15 11:08:47 2021 From: github.com+15714253+anthonyvdotbe at openjdk.java.net (Anthony Vanelverdinghe) Date: Wed, 15 Sep 2021 11:08:47 GMT Subject: RFR: 8273655: content-types.properties files are missing some common types In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 09:46:21 GMT, Julia Boes wrote: > This change adds some common types to the content-type.properties files, notably .js, .css, and .jar, as well as some others. > > The duplicated entry for .zip is removed from the Windows properties file. src/java.base/unix/classes/sun/net/www/content-types.properties line 266: > 264: > 265: text/javascript: \ > 266: description=Javascript File;\ JavaScript src/java.base/unix/classes/sun/net/www/content-types.properties line 323: > 321: file_extensions=.xml > 322: > 323: application/rtf: \ I'd also add an entry for `text/markdown` src/java.base/unix/classes/sun/net/www/content-types.properties line 324: > 322: > 323: application/rtf: \ > 324: description=Wordpad Document;\ WordPad src/java.base/unix/classes/sun/net/www/content-types.properties line 326: > 324: description=Wordpad Document;\ > 325: file_extensions=.rtf; > 326: Maybe add entries for the equivalent OpenDocument formats as well? src/java.base/unix/classes/sun/net/www/content-types.properties line 327: > 325: file_extensions=.rtf; > 326: > 327: application/xls: \ application/vnd.ms-excel src/java.base/unix/classes/sun/net/www/content-types.properties line 328: > 326: > 327: application/xls: \ > 328: description=XLS File;\ I'd describe the Office formats as "Microsoft Word/Excel/PowerPoint" src/java.base/unix/classes/sun/net/www/content-types.properties line 331: > 329: file_extensions=.xls; > 330: > 331: application/xlsx: \ application/vnd.openxmlformats-officedocument.spreadsheetml.sheet src/java.base/unix/classes/sun/net/www/content-types.properties line 339: > 337: file_extensions=.csv; > 338: > 339: application/pptx: \ application/vnd.openxmlformats-officedocument.presentationml.presentation src/java.base/unix/classes/sun/net/www/content-types.properties line 343: > 341: file_extensions=.pptx; > 342: > 343: application/ppt: \ application/vnd.ms-powerpoint src/java.base/unix/classes/sun/net/www/content-types.properties line 347: > 345: file_extensions=.ppt; > 346: > 347: application/7z: \ application/x-7z-compressed src/java.base/unix/classes/sun/net/www/content-types.properties line 348: > 346: > 347: application/7z: \ > 348: description=7z File;\ 7-Zip File src/java.base/unix/classes/sun/net/www/content-types.properties line 351: > 349: file_extensions=.7z; > 350: > 351: application/doc: \ application/msword src/java.base/unix/classes/sun/net/www/content-types.properties line 355: > 353: file_extensions=.doc; > 354: > 355: application/docx: \ application/vnd.openxmlformats-officedocument.wordprocessingml.document src/java.base/unix/classes/sun/net/www/content-types.properties line 359: > 357: file_extensions=.docx; > 358: > 359: application/php: \ Since e.g. `.java` and `.pl` are already listed as file extensions under `text/plain`, I'd add `.php` there, and add `.adoc` (AsciiDoc), `.ts` (TypeScript) and `.py` (Python) as well. src/java.base/unix/classes/sun/net/www/content-types.properties line 363: > 361: file_extensions=.php; > 362: > 363: application/rar: \ application/vnd.rar src/java.base/windows/classes/sun/net/www/content-types.properties line 30: > 28: application/octet-stream: \ > 29: description=Generic Binary Stream;\ > 30: file_extensions=.saveme,.dump,.hqx,.arc,.obj,.lib,.bin,.exe,.gz `.gz` has a registered media type and should be a separate entry ------------- PR: https://git.openjdk.java.net/jdk/pull/5506 From jboes at openjdk.java.net Wed Sep 15 17:25:47 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 15 Sep 2021 17:25:47 GMT Subject: RFR: 8273655: content-types.properties files are missing some common types In-Reply-To: References: Message-ID: <1SCFET1XWku6xQkyrxhMp-pDHJWAfpylPEQBPPIndaI=.bc180255-a21e-4c91-b75b-71f4622a7d2d@github.com> On Tue, 14 Sep 2021 09:46:21 GMT, Julia Boes wrote: > This change adds some common types to the content-type.properties files, notably .js, .css, and .jar, as well as some others. > > The duplicated entry for .zip is removed from the Windows properties file. > _Mailing list message from [Bernd Eckenfels](mailto:ecki at zusammenkunft.net) on [net-dev](mailto:net-dev at mail.openjdk.java.net):_ > > In the Test List .xml is not mentioned, that looks like a major format. > > However I am not sure if it maybe needs extra handling because of possible different mime types for application/xml and text/xml? .xml is already contained in the properties files as such: application/xml: \ description=XML document;\ file_extensions=.xml application/xml seems to be the default type as per RFC7303 [1], I think it should suffice in this context. Only the new types are added to the test. [1] https://datatracker.ietf.org/doc/html/rfc7303#section-4.1 ------------- PR: https://git.openjdk.java.net/jdk/pull/5506 From jboes at openjdk.java.net Thu Sep 16 15:28:36 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 16 Sep 2021 15:28:36 GMT Subject: RFR: 8273655: content-types.properties files are missing some common types [v2] In-Reply-To: References: Message-ID: <2AZNWbkIPPbr5qvOFBbKVw1eavOhnoFaXShh3_ElUa4=.9c97b979-b608-432c-9ac8-1d1ab78b25f1@github.com> > This change adds some common types to the content-type.properties files, notably .js, .css, and .jar, as well as some others. > > The duplicated entry for .zip is removed from the Windows properties file. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: address PR comments and refactor test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5506/files - new: https://git.openjdk.java.net/jdk/pull/5506/files/63565c5b..c7512889 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5506&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5506&range=00-01 Stats: 179 lines in 3 files changed: 70 ins; 45 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/5506.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5506/head:pull/5506 PR: https://git.openjdk.java.net/jdk/pull/5506 From jboes at openjdk.java.net Thu Sep 16 15:40:50 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 16 Sep 2021 15:40:50 GMT Subject: RFR: 8273655: content-types.properties files are missing some common types [v2] In-Reply-To: <2AZNWbkIPPbr5qvOFBbKVw1eavOhnoFaXShh3_ElUa4=.9c97b979-b608-432c-9ac8-1d1ab78b25f1@github.com> References: <2AZNWbkIPPbr5qvOFBbKVw1eavOhnoFaXShh3_ElUa4=.9c97b979-b608-432c-9ac8-1d1ab78b25f1@github.com> Message-ID: <2XdPc8mWJgrSEndEpc85FbheXXd_foVTVSvHEf0idFw=.1845cf04-bb98-42d2-9da6-f61f1d24d43a@github.com> On Thu, 16 Sep 2021 15:28:36 GMT, Julia Boes wrote: >> This change adds some common types to the content-type.properties files, notably .js, .css, and .jar, as well as some others. >> >> The duplicated entry for .zip is removed from the Windows properties file. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > address PR comments and refactor test @anthonyvdotbe Thanks for the comments, I incorporated them with one exception: I didn't add typescript (.ts) as it conflicts with MPEG transport stream on several platforms. A note on the test: I refactored it slightly to account for platform-specific type detection, for example in the case of .js, which is mapped to `application/javascript` on linux-aarch64 rather than `text/javascript`. The reason for this deviation is that the test uses `Files.probeContentType`, which only falls back to the content-types.properties file if no file type detector is installed. Testing: tier1-3 all clear. ------------- PR: https://git.openjdk.java.net/jdk/pull/5506 From prr at openjdk.java.net Thu Sep 16 18:09:49 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 16 Sep 2021 18:09:49 GMT Subject: RFR: 8273655: content-types.properties files are missing some common types [v2] In-Reply-To: <2AZNWbkIPPbr5qvOFBbKVw1eavOhnoFaXShh3_ElUa4=.9c97b979-b608-432c-9ac8-1d1ab78b25f1@github.com> References: <2AZNWbkIPPbr5qvOFBbKVw1eavOhnoFaXShh3_ElUa4=.9c97b979-b608-432c-9ac8-1d1ab78b25f1@github.com> Message-ID: <7nDGqVM-K3EL4TjfH3b2rBVJ4WsE6ObybN3mCh2qFMg=.4e021575-04fa-448d-a23c-73b1047132aa@github.com> On Thu, 16 Sep 2021 15:28:36 GMT, Julia Boes wrote: >> This change adds some common types to the content-type.properties files, notably .js, .css, and .jar, as well as some others. >> >> The duplicated entry for .zip is removed from the Windows properties file. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > address PR comments and refactor test I don't understand why these files are platform-specific. And if each platform port does need one, where is the one for macOS ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5506 From jboes at openjdk.java.net Fri Sep 17 09:59:42 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 17 Sep 2021 09:59:42 GMT Subject: RFR: 8273655: content-types.properties files are missing some common types [v2] In-Reply-To: <7nDGqVM-K3EL4TjfH3b2rBVJ4WsE6ObybN3mCh2qFMg=.4e021575-04fa-448d-a23c-73b1047132aa@github.com> References: <2AZNWbkIPPbr5qvOFBbKVw1eavOhnoFaXShh3_ElUa4=.9c97b979-b608-432c-9ac8-1d1ab78b25f1@github.com> <7nDGqVM-K3EL4TjfH3b2rBVJ4WsE6ObybN3mCh2qFMg=.4e021575-04fa-448d-a23c-73b1047132aa@github.com> Message-ID: On Thu, 16 Sep 2021 18:06:53 GMT, Phil Race wrote: > I don't understand why these files are platform-specific. > And if each platform port does need one, where is the one for macOS ? I'm not an expert in the area, it's probably down to historic reasons? The Unix version would be for all Unix varieties, unless a more specific source file is provided (thanks to @Michael-Mc-Mahon). ------------- PR: https://git.openjdk.java.net/jdk/pull/5506 From github.com+22913521+1996scarlet at openjdk.java.net Sat Sep 18 10:05:15 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Sat, 18 Sep 2021 10:05:15 GMT Subject: RFR: 8273961: [testbug] jdk/nio/zipfs/ZipFSTester.java fails if the path has plus character Message-ID: Add the pre-processing to replace "+" by "%2b" which avoids `URLDecoder.decoder` changing the path unexpectedly. ------------- Commit messages: - 8273961: [testbug] jdk/nio/zipfs/ZipFSTester.java fails if the path has plus character Changes: https://git.openjdk.java.net/jdk/pull/5574/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5574&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273961 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5574/head:pull/5574 PR: https://git.openjdk.java.net/jdk/pull/5574 From lancea at openjdk.java.net Mon Sep 20 10:13:02 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 10:13:02 GMT Subject: RFR: 8273961: [testbug] jdk/nio/zipfs/ZipFSTester.java fails if the path has plus character In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 09:57:12 GMT, Remilia Scarlet wrote: > Add the pre-processing to replace "+" by "%2b" which avoids `URLDecoder.decoder` changing the path unexpectedly. > > Please review this change. Thanks! test/jdk/jdk/nio/zipfs/ZipFSTester.java line 689: > 687: throws Exception > 688: { > 689: var plusReplacedUri = path.toUri().toString().replace("+", "%2b"); Thank you for your proposed patch. The path described in the bug is a bit unusual and not something we typically expect (or have seen). Please add a comment describing the purpose(maybe include a trivial example) of this change to make it more readily apparent to future maintainers. Not sure I am enamored with the name of the variable `plusReplacedUri`. Perhaps consider an alternative name. ------------- PR: https://git.openjdk.java.net/jdk/pull/5574 From lancea at openjdk.java.net Mon Sep 20 11:23:21 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 11:23:21 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported Message-ID: Hi all, Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. Mach5 tiers1 - tier3 are clean. Best Lance ------------- Commit messages: - Add Cleanup Method - adjust copyright - Files.getFileAttributeView() throws UOE instead of returning null when view not supported Changes: https://git.openjdk.java.net/jdk/pull/5579/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5579&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273935 Stats: 107 lines in 3 files changed: 103 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5579.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5579/head:pull/5579 PR: https://git.openjdk.java.net/jdk/pull/5579 From alanb at openjdk.java.net Mon Sep 20 11:33:58 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 20 Sep 2021 11:33:58 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: References: Message-ID: <1dFdOqhAEE23RUb_-3dq26cgFAnLlMm5UvBrpt9l2XU=.7c43b1a8-4414-4f9e-8831-9e6791a47e6d@github.com> On Sun, 19 Sep 2021 15:34:44 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance Marked as reviewed by alanb (Reviewer). src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java line 716: > 714: return (V)new ZipPosixFileAttributeView(this,true); > 715: } > 716: return (V) null; I assume (V) isn't needed here. test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 59: > 57: public void setup() throws IOException { > 58: Files.deleteIfExists(ZIP_FILE); > 59: Entry e0 = Entry.of(ZIP_ENTRY, ZipEntry.DEFLATED, Is there a reason why this is named "e0"? test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 82: > 80: return new Object[][]{ > 81: {Map.of()}, > 82: { Map.of("enablePosixFileAttributes", "true")} Minor nit, inconsistent formatting with L81 vs. L82. test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 89: > 87: * Verify that Files.getFileAttributeView will not throw > 88: * UnsupportedOperationException when the attribute view > 89: * PosixFileAttributeView is not available Might be clearer to say that it checks that Files.getFileAttributeView does not throw an exception (no need to mention UOE) when PosixFileAttributeView is not supported. test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 95: > 93: @Test(dataProvider = "zipfsMap") > 94: public void testPosixAttributeView(Map env) throws Exception { > 95: Spurious blank line. ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From github.com+22913521+1996scarlet at openjdk.java.net Mon Sep 20 14:12:03 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Mon, 20 Sep 2021 14:12:03 GMT Subject: RFR: 8273961: [testbug] jdk/nio/zipfs/ZipFSTester.java fails if the path has plus character In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 10:09:39 GMT, Lance Andersen wrote: >> Add the pre-processing to replace "+" by "%2b" which avoids `URLDecoder.decoder` changing the path unexpectedly. >> >> Please review this change. Thanks! > > test/jdk/jdk/nio/zipfs/ZipFSTester.java line 689: > >> 687: throws Exception >> 688: { >> 689: var plusReplacedUri = path.toUri().toString().replace("+", "%2b"); > > Thank you for your proposed patch. > > The path described in the bug is a bit unusual and not something we typically expect (or have seen). > > Please add a comment describing the purpose(maybe include a trivial example) of this change to make it more readily apparent to future maintainers. > > Not sure I am enamored with the name of the variable `plusReplacedUri`. Perhaps consider an alternative name. Thanks. It is a good idea to comment more information for maintainers. BTW, this bug is caused by the `newZipFileSystem` method, which assert its parameter `Path path` is utf-8 encoded. However, the path would not be encoded in most cases. So the `URLDecoder.decode(path.toUri().toString(), "utf8")` at line 692 may cause unexpected results, Maybe just remove the utf-8 decode logic is a valid option. What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/5574 From sgehwolf at openjdk.java.net Mon Sep 20 17:08:54 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 20 Sep 2021 17:08:54 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: References: Message-ID: On Sun, 19 Sep 2021 15:34:44 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 100: > 98: PosixFileAttributeView view = Files.getFileAttributeView(entry, > 99: PosixFileAttributeView.class); > 100: System.out.printf("View returned: %s%n", view); It might be useful to also print whether the environment is empty: Suggestion: `System.out.printf("View returned: %s, (empty_env=%s)%n", view, env.isEmpty());` ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From bpb at openjdk.java.net Mon Sep 20 17:13:09 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 20 Sep 2021 17:13:09 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: References: Message-ID: On Sun, 19 Sep 2021 15:34:44 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From bpb at openjdk.java.net Mon Sep 20 17:18:53 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 20 Sep 2021 17:18:53 GMT Subject: RFR: 8273655: content-types.properties files are missing some common types [v2] In-Reply-To: <2AZNWbkIPPbr5qvOFBbKVw1eavOhnoFaXShh3_ElUa4=.9c97b979-b608-432c-9ac8-1d1ab78b25f1@github.com> References: <2AZNWbkIPPbr5qvOFBbKVw1eavOhnoFaXShh3_ElUa4=.9c97b979-b608-432c-9ac8-1d1ab78b25f1@github.com> Message-ID: On Thu, 16 Sep 2021 15:28:36 GMT, Julia Boes wrote: >> This change adds some common types to the content-type.properties files, notably .js, .css, and .jar, as well as some others. >> >> The duplicated entry for .zip is removed from the Windows properties file. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > address PR comments and refactor test Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5506 From lancea at openjdk.java.net Mon Sep 20 18:08:49 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 18:08:49 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: <1dFdOqhAEE23RUb_-3dq26cgFAnLlMm5UvBrpt9l2XU=.7c43b1a8-4414-4f9e-8831-9e6791a47e6d@github.com> References: <1dFdOqhAEE23RUb_-3dq26cgFAnLlMm5UvBrpt9l2XU=.7c43b1a8-4414-4f9e-8831-9e6791a47e6d@github.com> Message-ID: On Mon, 20 Sep 2021 11:28:10 GMT, Alan Bateman wrote: >> Hi all, >> >> Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. >> >> Mach5 tiers1 - tier3 are clean. >> >> Best >> Lance > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java line 716: > >> 714: return (V)new ZipPosixFileAttributeView(this,true); >> 715: } >> 716: return (V) null; > > I assume (V) isn't needed here. No, it is not and can also probably be removed from open/src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java at some point > test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 59: > >> 57: public void setup() throws IOException { >> 58: Files.deleteIfExists(ZIP_FILE); >> 59: Entry e0 = Entry.of(ZIP_ENTRY, ZipEntry.DEFLATED, > > Is there a reason why this is named "e0"? Not really. Historically that was the variable name format used in some of the Zip FS tests. I changed the name to `entry` > test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 82: > >> 80: return new Object[][]{ >> 81: {Map.of()}, >> 82: { Map.of("enablePosixFileAttributes", "true")} > > Minor nit, inconsistent formatting with L81 vs. L82. Fixed, thanks for catching that. > test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 89: > >> 87: * Verify that Files.getFileAttributeView will not throw >> 88: * UnsupportedOperationException when the attribute view >> 89: * PosixFileAttributeView is not available > > Might be clearer to say that it checks that Files.getFileAttributeView does not throw an exception (no need to mention UOE) when PosixFileAttributeView is not supported. Updated per your suggestion! > test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 95: > >> 93: @Test(dataProvider = "zipfsMap") >> 94: public void testPosixAttributeView(Map env) throws Exception { >> 95: > > Spurious blank line. Removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From lancea at openjdk.java.net Mon Sep 20 18:08:50 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 18:08:50 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: References: Message-ID: <3bWbP-B1UC3dkCFcixhXyVw6IQPmaPsXG2-5MV3qnY0=.a78bd0f5-f3ef-41d7-87c4-caa40b921c40@github.com> On Mon, 20 Sep 2021 17:05:33 GMT, Severin Gehwolf wrote: >> Hi all, >> >> Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. >> >> Mach5 tiers1 - tier3 are clean. >> >> Best >> Lance > > test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java line 100: > >> 98: PosixFileAttributeView view = Files.getFileAttributeView(entry, >> 99: PosixFileAttributeView.class); >> 100: System.out.printf("View returned: %s%n", view); > > It might be useful to also print whether the environment is empty: > Suggestion: `System.out.printf("View returned: %s, (empty_env=%s)%n", view, env.isEmpty());` Well, you can see that whether the Map is/is not empty in the jtr file for the test run (based on the DataProvider Properties for a given run). However, per your suggestion, I tweaked the test to dump the Map values. ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From lancea at openjdk.java.net Mon Sep 20 18:15:33 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 18:15:33 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Updates based on feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5579/files - new: https://git.openjdk.java.net/jdk/pull/5579/files/e814a9f1..6ff49197 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5579&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5579&range=00-01 Stats: 12 lines in 3 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5579.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5579/head:pull/5579 PR: https://git.openjdk.java.net/jdk/pull/5579 From lancea at openjdk.java.net Mon Sep 20 18:17:29 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 18:17:29 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v3] In-Reply-To: References: Message-ID: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: fix minor typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5579/files - new: https://git.openjdk.java.net/jdk/pull/5579/files/6ff49197..65184a5a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5579&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5579&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5579.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5579/head:pull/5579 PR: https://git.openjdk.java.net/jdk/pull/5579 From lancea at openjdk.java.net Mon Sep 20 18:25:55 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 20 Sep 2021 18:25:55 GMT Subject: RFR: 8273961: [testbug] jdk/nio/zipfs/ZipFSTester.java fails if the path has plus character In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 14:08:13 GMT, Remilia Scarlet wrote: >> test/jdk/jdk/nio/zipfs/ZipFSTester.java line 689: >> >>> 687: throws Exception >>> 688: { >>> 689: var plusReplacedUri = path.toUri().toString().replace("+", "%2b"); >> >> Thank you for your proposed patch. >> >> The path described in the bug is a bit unusual and not something we typically expect (or have seen). >> >> Please add a comment describing the purpose(maybe include a trivial example) of this change to make it more readily apparent to future maintainers. >> >> Not sure I am enamored with the name of the variable `plusReplacedUri`. Perhaps consider an alternative name. > > Thanks. It is a good idea to comment more information for maintainers. > > BTW, this bug is caused by the `newZipFileSystem` method, which assert its parameter `Path path` is utf-8 encoded. > However, the path would not be encoded in most cases. > So the `URLDecoder.decode(path.toUri().toString(), "utf8")` at line 692 may cause unexpected results, > > Maybe just remove the utf-8 decode logic is a valid option. What do you think? We should leave it as is for now as it does test newFileSystem via a URI which is also supported. Certainly it could be updated at a later date when replacement is added(or at least more coverage) to exercise Zip FS, newFileSystem via URI. ------------- PR: https://git.openjdk.java.net/jdk/pull/5574 From alanb at openjdk.java.net Mon Sep 20 18:35:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 20 Sep 2021 18:35:56 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v3] In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 18:17:29 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. >> >> Mach5 tiers1 - tier3 are clean. >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > fix minor typo Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From bpb at openjdk.java.net Mon Sep 20 18:42:57 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 20 Sep 2021 18:42:57 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v3] In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 18:17:29 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. >> >> Mach5 tiers1 - tier3 are clean. >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > fix minor typo Marked as reviewed by bpb (Reviewer). Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From dfuchs at openjdk.java.net Mon Sep 20 19:13:00 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 20 Sep 2021 19:13:00 GMT Subject: RFR: 8273655: content-types.properties files are missing some common types [v2] In-Reply-To: <2AZNWbkIPPbr5qvOFBbKVw1eavOhnoFaXShh3_ElUa4=.9c97b979-b608-432c-9ac8-1d1ab78b25f1@github.com> References: <2AZNWbkIPPbr5qvOFBbKVw1eavOhnoFaXShh3_ElUa4=.9c97b979-b608-432c-9ac8-1d1ab78b25f1@github.com> Message-ID: On Thu, 16 Sep 2021 15:28:36 GMT, Julia Boes wrote: >> This change adds some common types to the content-type.properties files, notably .js, .css, and .jar, as well as some others. >> >> The duplicated entry for .zip is removed from the Windows properties file. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > address PR comments and refactor test Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5506 From bpb at openjdk.java.net Tue Sep 21 02:19:44 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 02:19:44 GMT Subject: RFR: 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout Message-ID: Change the test to run in `othervm` mode. ------------- Commit messages: - 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout Changes: https://git.openjdk.java.net/jdk/pull/5593/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5593&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272759 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5593.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5593/head:pull/5593 PR: https://git.openjdk.java.net/jdk/pull/5593 From bpb at openjdk.java.net Tue Sep 21 02:28:06 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 02:28:06 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) Message-ID: Modify `sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsPath,String)` to handle file names which exceed the limit. ------------- Commit messages: - 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) Changes: https://git.openjdk.java.net/jdk/pull/5594/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5594&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273922 Stats: 59 lines in 2 files changed: 45 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/5594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5594/head:pull/5594 PR: https://git.openjdk.java.net/jdk/pull/5594 From github.com+22913521+1996scarlet at openjdk.java.net Tue Sep 21 05:42:11 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Tue, 21 Sep 2021 05:42:11 GMT Subject: RFR: 8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character [v2] In-Reply-To: References: Message-ID: > Add the pre-processing to replace "+" by "%2b" which avoids `URLDecoder.decoder` changing the path unexpectedly. > > Please review this change. Thanks! Remilia Scarlet 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: 8273961: [testbug] jdk/nio/zipfs/ZipFSTester.java fails if the path has plus character ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5574/files - new: https://git.openjdk.java.net/jdk/pull/5574/files/e66bbd37..4e07d675 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5574&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5574&range=00-01 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5574/head:pull/5574 PR: https://git.openjdk.java.net/jdk/pull/5574 From github.com+22913521+1996scarlet at openjdk.java.net Tue Sep 21 05:42:11 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Tue, 21 Sep 2021 05:42:11 GMT Subject: RFR: 8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 09:57:12 GMT, Remilia Scarlet wrote: > Add the pre-processing to replace "+" by "%2b" which avoids `URLDecoder.decoder` changing the path unexpectedly. > > Please review this change. Thanks! Please reexamine this change. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5574 From alanb at openjdk.java.net Tue Sep 21 06:10:57 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 21 Sep 2021 06:10:57 GMT Subject: RFR: 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 02:07:49 GMT, Brian Burkhalter wrote: > Change the test to run in `othervm` mode. There isn't enough information in the JBS issue or this PR to comment on whether this test should be run in agentvm or othervm mode. From what I can see, the test periodically times out on macOS machines but I can't see if this is just older machines or whether there is a concern that output isn't seen in the .jtr file when run in agentvm mode. ------------- PR: https://git.openjdk.java.net/jdk/pull/5593 From jboes at openjdk.java.net Tue Sep 21 08:10:56 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 21 Sep 2021 08:10:56 GMT Subject: Integrated: 8273655: content-types.properties files are missing some common types In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 09:46:21 GMT, Julia Boes wrote: > This change adds some common types to the content-type.properties files, notably .js, .css, and .jar, as well as some others. > > The duplicated entry for .zip is removed from the Windows properties file. This pull request has now been integrated. Changeset: 65ed0a74 Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/65ed0a742e65fe7e661e8da2adea6cd41992869e Stats: 227 lines in 3 files changed: 193 ins; 13 del; 21 mod 8273655: content-types.properties files are missing some common types Reviewed-by: bpb, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5506 From sgehwolf at openjdk.java.net Tue Sep 21 08:12:51 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 21 Sep 2021 08:12:51 GMT Subject: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v3] In-Reply-To: References: Message-ID: <-W3koaB1U4hHdmmpFWH6fhmUFMZ6G-4E1heM0a6_sdY=.8215a059-e0ad-446d-970d-a4e84c5c0815@github.com> On Mon, 20 Sep 2021 18:17:29 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. >> >> Mach5 tiers1 - tier3 are clean. >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > fix minor typo Marked as reviewed by sgehwolf (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From clanger at openjdk.java.net Tue Sep 21 08:21:45 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 21 Sep 2021 08:21:45 GMT Subject: RFR: 8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character [v2] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 05:42:11 GMT, Remilia Scarlet wrote: >> Add the pre-processing to replace "+" by "%2b" which avoids `URLDecoder.decoder` changing the path unexpectedly. >> >> Please review this change. Thanks! > > Remilia Scarlet 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. Changes requested by clanger (Reviewer). test/jdk/jdk/nio/zipfs/ZipFSTester.java line 704: > 702: // character > 703: return FileSystems.newFileSystem( > 704: new URI("jar", URLDecoder.decode(encoded, "utf8"), instead of using local variable encoded, I would just add the call to .replace("+", "%2b") inline. The comments look good, I would suggest to put them between line 702/703. ------------- PR: https://git.openjdk.java.net/jdk/pull/5574 From github.com+22913521+1996scarlet at openjdk.java.net Tue Sep 21 10:17:33 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Tue, 21 Sep 2021 10:17:33 GMT Subject: RFR: 8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character [v3] In-Reply-To: References: Message-ID: > Add the pre-processing to replace "+" by "%2b" which avoids `URLDecoder.decoder` changing the path unexpectedly. > > Please review this change. Thanks! Remilia Scarlet 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: 8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5574/files - new: https://git.openjdk.java.net/jdk/pull/5574/files/4e07d675..be7c1fdf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5574&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5574&range=01-02 Stats: 8 lines in 1 file changed: 1 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5574/head:pull/5574 PR: https://git.openjdk.java.net/jdk/pull/5574 From github.com+22913521+1996scarlet at openjdk.java.net Tue Sep 21 10:17:36 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Tue, 21 Sep 2021 10:17:36 GMT Subject: RFR: 8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character [v2] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 08:19:00 GMT, Christoph Langer wrote: >> Remilia Scarlet has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > test/jdk/jdk/nio/zipfs/ZipFSTester.java line 704: > >> 702: // character >> 703: return FileSystems.newFileSystem( >> 704: new URI("jar", URLDecoder.decode(encoded, "utf8"), > > instead of using local variable encoded, I would just add the call to .replace("+", "%2b") inline. > > The comments look good, I would suggest to put them between line 702/703. Done. A new patch has been uploaded. ------------- PR: https://git.openjdk.java.net/jdk/pull/5574 From bpb at openjdk.java.net Tue Sep 21 16:03:59 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 16:03:59 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v2] In-Reply-To: References: Message-ID: <6B7UxP42J7YqO3zy-oPaUY2MH-k2V9FzHL_zRa8dYvE=.adbcb921-4e73-4a8f-9a0a-660025746b38@github.com> > Modify `sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsPath,String)` to handle file names which exceed the limit. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8273922: Add bug ID to @bug in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5594/files - new: https://git.openjdk.java.net/jdk/pull/5594/files/2e0a2f68..3b2b560a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5594&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5594&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5594/head:pull/5594 PR: https://git.openjdk.java.net/jdk/pull/5594 From bpb at openjdk.java.net Tue Sep 21 16:20:34 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 16:20:34 GMT Subject: RFR: 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 02:07:49 GMT, Brian Burkhalter wrote: > Change the test to run in `othervm` mode. All failures but one so far are on the same machine and all failures are on a [MacPro5,1](https://support.apple.com/kb/SP589?locale=en_US), which is vintage mid-2010. Otherwise, the logs do not contain significant useful information because of timing out. ------------- PR: https://git.openjdk.java.net/jdk/pull/5593 From lancea at openjdk.java.net Tue Sep 21 18:06:33 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 21 Sep 2021 18:06:33 GMT Subject: RFR: 8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character [v3] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 10:17:33 GMT, Remilia Scarlet wrote: >> Add the pre-processing to replace "+" by "%2b" which avoids `URLDecoder.decoder` changing the path unexpectedly. >> >> Please review this change. Thanks! > > Remilia Scarlet 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. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5574 From clanger at openjdk.java.net Tue Sep 21 18:10:35 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 21 Sep 2021 18:10:35 GMT Subject: RFR: 8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character [v3] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 10:17:33 GMT, Remilia Scarlet wrote: >> Add the pre-processing to replace "+" by "%2b" which avoids `URLDecoder.decoder` changing the path unexpectedly. >> >> Please review this change. Thanks! > > Remilia Scarlet 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. Marked as reviewed by clanger (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5574 From alanb at openjdk.java.net Tue Sep 21 18:41:33 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 21 Sep 2021 18:41:33 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v2] In-Reply-To: <6B7UxP42J7YqO3zy-oPaUY2MH-k2V9FzHL_zRa8dYvE=.adbcb921-4e73-4a8f-9a0a-660025746b38@github.com> References: <6B7UxP42J7YqO3zy-oPaUY2MH-k2V9FzHL_zRa8dYvE=.adbcb921-4e73-4a8f-9a0a-660025746b38@github.com> Message-ID: On Tue, 21 Sep 2021 16:03:59 GMT, Brian Burkhalter wrote: >> Modify `sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsPath,String)` to handle file names which exceed the limit. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8273922: Add bug ID to @bug in test src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java line 62: > 60: StringBuilder sb = new StringBuilder(wp.getPathForWin32Calls()); > 61: sb.setCharAt(sb.length() - name.length() - 1, ':'); > 62: return sb.toString(); I suspect the right thing here is to parse "name" and maybe reject if it is not RELATIVE. Then concatenate and use createFromNormalizedPath(...) to create the WindowsPath. I expect it will be possible to reduce the number of conversions too although this isn't critical for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From bpb at openjdk.java.net Tue Sep 21 19:28:58 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 21 Sep 2021 19:28:58 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v3] In-Reply-To: References: Message-ID: > Modify `sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsPath,String)` to handle file names which exceed the limit. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8273922: Make join() reject absolute path in 1nth in 'name' parameter ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5594/files - new: https://git.openjdk.java.net/jdk/pull/5594/files/3b2b560a..5be22533 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5594&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5594&range=01-02 Stats: 15 lines in 2 files changed: 9 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5594/head:pull/5594 PR: https://git.openjdk.java.net/jdk/pull/5594 From lancea at openjdk.java.net Tue Sep 21 19:43:24 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 21 Sep 2021 19:43:24 GMT Subject: Integrated: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported In-Reply-To: References: Message-ID: <3TtA8XpYByMzr-43PVIR3NZsWd3ZQDOVe_L0ArZwUMI=.2bb90053-4418-40a3-9e04-d5984d86d092@github.com> On Sun, 19 Sep 2021 15:34:44 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a UOE instead of returning null when Files.getFileAttributeView() is invoked and the view not supported. > > Mach5 tiers1 - tier3 are clean. > > Best > Lance This pull request has now been integrated. Changeset: 161fdb4a Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/161fdb4afbc6e67cc7580fe753112c4d894a9b6b Stats: 108 lines in 4 files changed: 102 ins; 0 del; 6 mod 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported Reviewed-by: alanb, bpb, sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/5579 From bpb at openjdk.java.net Wed Sep 22 01:35:09 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 01:35:09 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() Message-ID: Please consider this patch which would improve the performance of `FileChannel.transferTo()` on macOS and Windows. ------------- Commit messages: - 8274112: (fc) Tune FileChannel.transferTo() Changes: https://git.openjdk.java.net/jdk/pull/5623/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5623&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274112 Stats: 122 lines in 5 files changed: 108 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/5623.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5623/head:pull/5623 PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Wed Sep 22 01:35:09 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 01:35:09 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() In-Reply-To: References: Message-ID: <-E2LwdbAo_ZvtdODz0X3I4AW7vBauxMXK-rEnybcoRo=.933d3822-964b-459a-9ae4-65334c43c787@github.com> On Wed, 22 Sep 2021 01:25:37 GMT, Brian Burkhalter wrote: > Please consider this patch which would improve the performance of > `FileChannel.transferTo()` on macOS and Windows. On Linux, `sendfile()` was measured to provide faster transfer than either the trusted channel (mapped buffer copy) or the arbitrary channel (Java read-write) paths, and an experimental native read-write path. Therefor on Linux no change is needed. On macOS, native read-write was measured to be faster than both the trusted and arbitrary paths. Benchmark results for various lengths are for the trusted path Benchmark (length) Mode Cnt Score Error Units TransferTune.transferToFC 1000 thrpt 10 127670.489 ? 1018.466 ops/s TransferTune.transferToFC 10000 thrpt 10 103345.306 ? 1049.713 ops/s TransferTune.transferToFC 100000 thrpt 10 36488.102 ? 242.382 ops/s TransferTune.transferToFC 500000 thrpt 10 9440.104 ? 56.543 ops/s TransferTune.transferToFC 1000000 thrpt 10 4813.599 ? 78.812 ops/s TransferTune.transferToFC 10000000 thrpt 10 184.298 ? 4.617 ops/s TransferTune.transferToFC 100000000 thrpt 10 23.391 ? 0.183 ops/s TransferTune.transferToFC 500000000 thrpt 10 4.674 ? 0.028 ops/s TransferTune.transferToFC 1000000000 thrpt 10 2.349 ? 0.010 ops/s TransferTune.transferToFC 2000000000 thrpt 10 0.993 ? 0.004 ops/s TransferTune.transferToFC 4000000000 thrpt 10 0.455 ? 0.002 ops/s and the proposed native read-write path Benchmark (length) Mode Cnt Score Error Units TransferTune.transferToFC 1000 thrpt 10 253841.238 ? 1884.480 ops/s TransferTune.transferToFC 10000 thrpt 10 215629.254 ? 1987.146 ops/s TransferTune.transferToFC 100000 thrpt 10 48655.924 ? 1060.983 ops/s TransferTune.transferToFC 500000 thrpt 10 11596.874 ? 126.086 ops/s TransferTune.transferToFC 1000000 thrpt 10 5889.314 ? 20.170 ops/s TransferTune.transferToFC 10000000 thrpt 10 364.018 ? 2.149 ops/s TransferTune.transferToFC 100000000 thrpt 10 31.956 ? 0.277 ops/s TransferTune.transferToFC 500000000 thrpt 10 6.282 ? 0.090 ops/s TransferTune.transferToFC 1000000000 thrpt 10 3.134 ? 0.103 ops/s TransferTune.transferToFC 2000000000 thrpt 10 1.542 ? 0.080 ops/s TransferTune.transferToFC 4000000000 thrpt 10 0.750 ? 0.087 ops/s On Windows the native read-write path was also measured to be faster than the trusted path except that beyond a certain limit the trusted path becomes faster than native read-write. The value of this limit appears to be approximately 2MB but more verification might be needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From alanb at openjdk.java.net Wed Sep 22 07:10:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 22 Sep 2021 07:10:56 GMT Subject: RFR: 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 02:07:49 GMT, Brian Burkhalter wrote: > Change the test to run in `othervm` mode. No objection to changing this test to othervm but if the timeouts are only seen on 2010 era Mac machines then I would think that the timeout will need to be increased, or the machines upgraded/replaced. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5593 From github.com+22913521+1996scarlet at openjdk.java.net Wed Sep 22 11:40:59 2021 From: github.com+22913521+1996scarlet at openjdk.java.net (Remilia Scarlet) Date: Wed, 22 Sep 2021 11:40:59 GMT Subject: Integrated: 8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 09:57:12 GMT, Remilia Scarlet wrote: > Add the pre-processing to replace "+" by "%2b" which avoids `URLDecoder.decoder` changing the path unexpectedly. > > Please review this change. Thanks! This pull request has now been integrated. Changeset: 7f78803b Author: sunxu Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/7f78803b0926ea194334ad9b3c9f06cbe17a83dd Stats: 14 lines in 1 file changed: 9 ins; 0 del; 5 mod 8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character Reviewed-by: clanger, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5574 From alanb at openjdk.java.net Wed Sep 22 13:28:58 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 22 Sep 2021 13:28:58 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v3] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 19:28:58 GMT, Brian Burkhalter wrote: >> Modify `sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsPath,String)` to handle file names which exceed the limit. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8273922: Make join() reject absolute path in 1nth in 'name' parameter src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java line 64: > 62: String path = join(file.getPathForWin32Calls(), name); > 63: WindowsPath wp = WindowsPath.createFromNormalizedPath(wfs, path); > 64: return wp.getPathForWin32Calls(); I think we can simplify this to avoid most of the conversions, I'll get back to you soon with a proposal for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From alanb at openjdk.java.net Wed Sep 22 13:36:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 22 Sep 2021 13:36:55 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 01:25:37 GMT, Brian Burkhalter wrote: > Please consider this patch which would improve the performance of > `FileChannel.transferTo()` on macOS and Windows. src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 559: > 557: int thisFDVal = IOUtil.fdVal(fd); > 558: int targetFDVal = IOUtil.fdVal(targetFD); > 559: if (thisFDVal != -1 && targetFDVal != -1 && thisFDVal == targetFDVal) How can the fd values be -1 here, we must have an issue somewhere else if this happens. src/java.base/share/classes/sun/nio/ch/IOStatus.java line 42: > 40: @Native public static final int THROWN = -5; // Exception thrown in JNI code > 41: @Native public static final int UNSUPPORTED_CASE = -6; // This case not supported > 42: @Native public static final int UNSUPPORTED_SUBCASE = -7; // This subcase not supported I think it's way too confusing to introduce an "unsupported subclass", I think we need to find a better solution for this. src/java.base/windows/native/libnio/ch/FileChannelImpl.c line 177: > 175: if (WriteFile(dst, &buf, nr, &nw, NULL) == 0) { > 176: JNU_ThrowIOExceptionWithLastError(env, "WriteFile failed"); > 177: return IOS_THROWN; If ReadFile or WriteFile fails then I assume we should return tw when > 0. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From alanb at openjdk.java.net Wed Sep 22 13:41:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 22 Sep 2021 13:41:56 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 01:25:37 GMT, Brian Burkhalter wrote: > Please consider this patch which would improve the performance of > `FileChannel.transferTo()` on macOS and Windows. No objection to try to improve the macOS and Windows cases but I'm concerned about the maintainability. It might be that we have to do significantly refactoring of the FileChannel implementation property support these cases. I think the native methods should be as simple as possible and all the decisions on the dispatching should be in the Java code, not the native code. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Wed Sep 22 16:40:52 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 16:40:52 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 01:25:37 GMT, Brian Burkhalter wrote: > Please consider this patch which would improve the performance of > `FileChannel.transferTo()` on macOS and Windows. I had considered adding a fourth path, `transferToFileChannel()`, which would be after the direct but before the trusted path. This would I think dispense with the `UNSUPPORTED_SUBCASE`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Wed Sep 22 16:40:55 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 16:40:55 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() In-Reply-To: References: Message-ID: <6bZ-LtLuXyWGLf3paXx27q07fwjOyGHRzBtamgI6hcI=.3ceec492-7dd5-489c-a5b9-4d565a2f93cf@github.com> On Wed, 22 Sep 2021 13:29:19 GMT, Alan Bateman wrote: >> Please consider this patch which would improve the performance of >> `FileChannel.transferTo()` on macOS and Windows. > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 559: > >> 557: int thisFDVal = IOUtil.fdVal(fd); >> 558: int targetFDVal = IOUtil.fdVal(targetFD); >> 559: if (thisFDVal != -1 && targetFDVal != -1 && thisFDVal == targetFDVal) > > How can the fd values be -1 here, we must have an issue somewhere else if this happens. On Windows this can happen. > src/java.base/windows/native/libnio/ch/FileChannelImpl.c line 177: > >> 175: if (WriteFile(dst, &buf, nr, &nw, NULL) == 0) { >> 176: JNU_ThrowIOExceptionWithLastError(env, "WriteFile failed"); >> 177: return IOS_THROWN; > > If ReadFile or WriteFile fails then I assume we should return tw when > 0. In the macOS code if `read()` or `write()` fails then an exception is thrown. I suppose the two read-write versions should be consistent one way or the other. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From alanb at openjdk.java.net Wed Sep 22 16:57:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 22 Sep 2021 16:57:53 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 16:37:37 GMT, Brian Burkhalter wrote: > I had considered adding a fourth path, `transferToFileChannel()`, which would be after the direct but before the trusted path. This would I think dispense with the `UNSUPPORTED_SUBCASE`. transferToDirectly already tests if the target is a FileChannel so I think a transferToFileChannel would be cleaner. My main concern is that there is many cases and have some in FCI and some in the native code makes it difficult to maintain. I'd prefer to have the native methods be simple "leaf" methods and all decisions are done in the FCI code. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Wed Sep 22 16:57:53 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 16:57:53 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 01:25:37 GMT, Brian Burkhalter wrote: > Please consider this patch which would improve the performance of > `FileChannel.transferTo()` on macOS and Windows. I agree about keeping the decisions at the Java level. I will work on refactoring this. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Wed Sep 22 16:35:09 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 16:35:09 GMT Subject: RFR: 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 02:07:49 GMT, Brian Burkhalter wrote: > Change the test to run in `othervm` mode. I am integrating this as is. If timeouts continue to be seen on ancient hardware then increasing the timeout may be considered at that point. ------------- PR: https://git.openjdk.java.net/jdk/pull/5593 From bpb at openjdk.java.net Wed Sep 22 16:35:10 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 16:35:10 GMT Subject: Integrated: 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 02:07:49 GMT, Brian Burkhalter wrote: > Change the test to run in `othervm` mode. This pull request has now been integrated. Changeset: 81d41647 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/81d416477f9856861a5af13058bfc3028bcb9b60 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5593 From bpb at openjdk.java.net Wed Sep 22 20:07:24 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 20:07:24 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v2] In-Reply-To: References: Message-ID: <67uw4S9IcxTIL5WmwJLRTg8-h4ZbvyqGiUPMy7AxsP8=.8a9e1b3a-f15b-482a-8f9c-14a4745cf6ec@github.com> > Please consider this patch which would improve the performance of > `FileChannel.transferTo()` on macOS and Windows. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274112: Refactor to use transferToFileChannel() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5623/files - new: https://git.openjdk.java.net/jdk/pull/5623/files/b0953032..e2eaeabe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5623&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5623&range=00-01 Stats: 416 lines in 9 files changed: 266 ins; 108 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/5623.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5623/head:pull/5623 PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Wed Sep 22 20:07:26 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 20:07:26 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 01:25:37 GMT, Brian Burkhalter wrote: > Please consider this patch which would improve the performance of > `FileChannel.transferTo()` on macOS and Windows. The second commit refactored `FileChannelImpl` to use `transferToFileChannel()` interposed between the direct and trusted paths. The performance measurements are little changed: Benchmark (length) Mode Cnt Score Error Units TransferTune.transferToFC 1000 thrpt 10 287559.646 ? 3136.563 ops/s TransferTune.transferToFC 10000 thrpt 10 238028.996 ? 3759.595 ops/s TransferTune.transferToFC 100000 thrpt 10 50048.757 ? 1462.758 ops/s TransferTune.transferToFC 500000 thrpt 10 11642.157 ? 99.617 ops/s TransferTune.transferToFC 1000000 thrpt 10 5950.070 ? 54.328 ops/s TransferTune.transferToFC 10000000 thrpt 10 363.774 ? 3.560 ops/s TransferTune.transferToFC 100000000 thrpt 10 32.454 ? 0.166 ops/s TransferTune.transferToFC 500000000 thrpt 10 6.506 ? 0.175 ops/s TransferTune.transferToFC 1000000000 thrpt 10 3.127 ? 0.121 ops/s TransferTune.transferToFC 2000000000 thrpt 10 1.555 ? 0.084 ops/s TransferTune.transferToFC 4000000000 thrpt 10 0.747 ? 0.101 ops/s the `transfer_read_write()` functions were _not_ changed as yet to return a positive `tw` if either the read or the write fails. The `UNSUPPORTED_SUBCASE` was removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Wed Sep 22 20:10:57 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 20:10:57 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v2] In-Reply-To: <6bZ-LtLuXyWGLf3paXx27q07fwjOyGHRzBtamgI6hcI=.3ceec492-7dd5-489c-a5b9-4d565a2f93cf@github.com> References: <6bZ-LtLuXyWGLf3paXx27q07fwjOyGHRzBtamgI6hcI=.3ceec492-7dd5-489c-a5b9-4d565a2f93cf@github.com> Message-ID: On Wed, 22 Sep 2021 16:33:58 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 559: >> >>> 557: int thisFDVal = IOUtil.fdVal(fd); >>> 558: int targetFDVal = IOUtil.fdVal(targetFD); >>> 559: if (thisFDVal != -1 && targetFDVal != -1 && thisFDVal == targetFDVal) >> >> How can the fd values be -1 here, we must have an issue somewhere else if this happens. > > On Windows this can happen. Removed in second commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Wed Sep 22 21:27:56 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 21:27:56 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v2] In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 13:30:26 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274112: Refactor to use transferToFileChannel() > > src/java.base/share/classes/sun/nio/ch/IOStatus.java line 42: > >> 40: @Native public static final int THROWN = -5; // Exception thrown in JNI code >> 41: @Native public static final int UNSUPPORTED_CASE = -6; // This case not supported >> 42: @Native public static final int UNSUPPORTED_SUBCASE = -7; // This subcase not supported > > I think it's way too confusing to introduce an "unsupported subclass", I think we need to find a better solution for this. Removed `IOStatus.UNSUPPORTED_SUBCASE` in second commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Wed Sep 22 22:51:11 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 22 Sep 2021 22:51:11 GMT Subject: RFR: 8274175: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java still failed in timeout Message-ID: Test still fails in `othervm` mode; increase the timeout value. ------------- Commit messages: - 8274175: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java still failed in timeout Changes: https://git.openjdk.java.net/jdk/pull/5642/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5642&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274175 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5642/head:pull/5642 PR: https://git.openjdk.java.net/jdk/pull/5642 From bpb at openjdk.java.net Thu Sep 23 02:01:07 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 02:01:07 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes Message-ID: This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. ------------- Commit messages: - 8268435: (ch) ChannelInputStream could override readAllBytes Changes: https://git.openjdk.java.net/jdk/pull/5645/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5645&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268435 Stats: 162 lines in 2 files changed: 134 ins; 12 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5645/head:pull/5645 PR: https://git.openjdk.java.net/jdk/pull/5645 From bpb at openjdk.java.net Thu Sep 23 02:04:00 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 02:04:00 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 01:52:31 GMT, Brian Burkhalter wrote: > This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. Throughput measured without the change for various stream lengths was Benchmark (length) Mode Cnt Score Error Units ChannelInputStream.readAllBytes 1000 thrpt 10 418393.824 ? 2969.676 ops/s ChannelInputStream.readAllBytes 10000 thrpt 10 196087.387 ? 1947.272 ops/s ChannelInputStream.readAllBytes 100000 thrpt 10 29089.090 ? 430.841 ops/s ChannelInputStream.readAllBytes 1000000 thrpt 10 2534.655 ? 5.373 ops/s ChannelInputStream.readAllBytes 10000000 thrpt 10 209.193 ? 1.106 ops/s ChannelInputStream.readAllBytes 100000000 thrpt 10 20.010 ? 0.047 ops/s ChannelInputStream.readAllBytes 1000000000 thrpt 10 1.455 ? 0.204 ops/s ChannelInputStream.readNBytes 1000 thrpt 10 544002.863 ? 1900.158 ops/s ChannelInputStream.readNBytes 10000 thrpt 10 421766.791 ? 2928.367 ops/s ChannelInputStream.readNBytes 100000 thrpt 10 57035.078 ? 214.834 ops/s ChannelInputStream.readNBytes 1000000 thrpt 10 5855.087 ? 52.283 ops/s ChannelInputStream.readNBytes 10000000 thrpt 10 427.560 ? 2.925 ops/s ChannelInputStream.readNBytes 100000000 thrpt 10 40.118 ? 0.091 ops/s ChannelInputStream.readNBytes 1000000000 thrpt 10 3.315 ? 0.434 ops/s and with the change in place was Benchmark (length) Mode Cnt Score Error Units ChannelInputStream.readAllBytes 1000 thrpt 10 337785.548 ? 2702.517 ops/s ChannelInputStream.readAllBytes 10000 thrpt 10 245969.721 ? 1362.465 ops/s ChannelInputStream.readAllBytes 100000 thrpt 10 75736.303 ? 321.443 ops/s ChannelInputStream.readAllBytes 1000000 thrpt 10 8835.464 ? 73.547 ops/s ChannelInputStream.readAllBytes 10000000 thrpt 10 370.141 ? 0.675 ops/s ChannelInputStream.readAllBytes 100000000 thrpt 10 34.029 ? 0.152 ops/s ChannelInputStream.readAllBytes 1000000000 thrpt 10 3.414 ? 0.032 ops/s ChannelInputStream.readNBytes 1000 thrpt 10 354884.272 ? 2264.808 ops/s ChannelInputStream.readNBytes 10000 thrpt 10 296775.457 ? 4296.873 ops/s ChannelInputStream.readNBytes 100000 thrpt 10 120579.221 ? 374.626 ops/s ChannelInputStream.readNBytes 1000000 thrpt 10 18079.568 ? 109.945 ops/s ChannelInputStream.readNBytes 10000000 thrpt 10 860.772 ? 2.333 ops/s ChannelInputStream.readNBytes 100000000 thrpt 10 69.266 ? 0.293 ops/s ChannelInputStream.readNBytes 1000000000 thrpt 10 6.840 ? 0.016 ops/s In effect, degraded performance for very small lengths is traded off against better performance for larger lengths. Note however that the `readNBytes()` measurements were made for `len = length/2` and so are less telling. Otherwise said, the `readAllBytes()` results are more straightforwardly interpreted. Adding a threshold was not investigated. Unfortunately this is mostly code duplication from `FileInputStream`. It would be better if there were a common location where the implementation could be placed and used by both cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/5645 From bpb at openjdk.java.net Thu Sep 23 02:07:30 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 02:07:30 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v3] In-Reply-To: References: Message-ID: > Please consider this patch which would improve the performance of > `FileChannel.transferTo()` on macOS and Windows. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274112: Modify transfer_read_write() not to throw if read or write fails ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5623/files - new: https://git.openjdk.java.net/jdk/pull/5623/files/e2eaeabe..6ad473da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5623&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5623&range=01-02 Stats: 19 lines in 2 files changed: 0 ins; 13 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5623.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5623/head:pull/5623 PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Thu Sep 23 02:07:32 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 02:07:32 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v3] In-Reply-To: <6bZ-LtLuXyWGLf3paXx27q07fwjOyGHRzBtamgI6hcI=.3ceec492-7dd5-489c-a5b9-4d565a2f93cf@github.com> References: <6bZ-LtLuXyWGLf3paXx27q07fwjOyGHRzBtamgI6hcI=.3ceec492-7dd5-489c-a5b9-4d565a2f93cf@github.com> Message-ID: On Wed, 22 Sep 2021 16:36:37 GMT, Brian Burkhalter wrote: >> src/java.base/windows/native/libnio/ch/FileChannelImpl.c line 177: >> >>> 175: if (WriteFile(dst, &buf, nr, &nw, NULL) == 0) { >>> 176: JNU_ThrowIOExceptionWithLastError(env, "WriteFile failed"); >>> 177: return IOS_THROWN; >> >> If ReadFile or WriteFile fails then I assume we should return tw when > 0. > > In the macOS code if `read()` or `write()` fails then an exception is thrown. I suppose the two read-write versions should be consistent one way or the other. This is resolved in commit three. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From alanb at openjdk.java.net Thu Sep 23 06:31:49 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 23 Sep 2021 06:31:49 GMT Subject: RFR: 8274175: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java still failed in timeout In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 22:44:38 GMT, Brian Burkhalter wrote: > Test still fails in `othervm` mode; increase the timeout value. I hope this is enough. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5642 From alanb at openjdk.java.net Thu Sep 23 06:50:00 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 23 Sep 2021 06:50:00 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v3] In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 02:07:30 GMT, Brian Burkhalter wrote: >> Please consider this patch which would improve the performance of >> `FileChannel.transferTo()` on macOS and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274112: Modify transfer_read_write() not to throw if read or write fails Thanks for the updates, this looks much cleaner and maintainable now. Busy just now so will look at it closer later. ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From prappo at openjdk.java.net Thu Sep 23 12:45:06 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 23 Sep 2021 12:45:06 GMT Subject: RFR: 8274195: Doc cleanup in java.nio.file Message-ID: Please review this trivial change triggered by reading the java.nio.file documentation for an unrelated code review. ------------- Commit messages: - Standardize wording in FileVisitResult constants - Update the copyright year - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/5649/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5649&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274195 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5649.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5649/head:pull/5649 PR: https://git.openjdk.java.net/jdk/pull/5649 From alanb at openjdk.java.net Thu Sep 23 13:01:02 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 23 Sep 2021 13:01:02 GMT Subject: RFR: 8274195: Doc cleanup in java.nio.file In-Reply-To: References: Message-ID: <1WJgg7gj3O0BZYuahzTC5thqGVt1qdTVSDuvFge6pMI=.d0db86d2-aad9-4e15-b9d1-b1a5cf019a48@github.com> On Thu, 23 Sep 2021 12:03:01 GMT, Pavel Rappo wrote: > Please review this trivial change triggered by reading the java.nio.file documentation for an unrelated code review. src/java.base/share/classes/java/nio/file/FileVisitResult.java line 40: > 38: * Continue. If returned from the {@link FileVisitor#preVisitDirectory > 39: * preVisitDirectory} method then the entries in the directory are also > 40: * visited. "When returned" -> "If returned" is okay. Returning CONTINUE is an indication to the caller that the entries should be visited, maybe leave it alone or else say "are also to be visited". ------------- PR: https://git.openjdk.java.net/jdk/pull/5649 From prappo at openjdk.java.net Thu Sep 23 13:14:52 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 23 Sep 2021 13:14:52 GMT Subject: RFR: 8274195: Doc cleanup in java.nio.file In-Reply-To: <1WJgg7gj3O0BZYuahzTC5thqGVt1qdTVSDuvFge6pMI=.d0db86d2-aad9-4e15-b9d1-b1a5cf019a48@github.com> References: <1WJgg7gj3O0BZYuahzTC5thqGVt1qdTVSDuvFge6pMI=.d0db86d2-aad9-4e15-b9d1-b1a5cf019a48@github.com> Message-ID: <30z51skbLc0BEz9y7tclUMZOTsXHdPq722FuOnHzKkg=.73c78fd1-50c9-4b78-b4be-8e551671c21b@github.com> On Thu, 23 Sep 2021 12:57:34 GMT, Alan Bateman wrote: >> Please review this trivial change triggered by reading the java.nio.file documentation for an unrelated code review. > > src/java.base/share/classes/java/nio/file/FileVisitResult.java line 40: > >> 38: * Continue. If returned from the {@link FileVisitor#preVisitDirectory >> 39: * preVisitDirectory} method then the entries in the directory are also >> 40: * visited. > > "When returned" -> "If returned" is okay. > Returning CONTINUE is an indication to the caller that the entries should be visited, maybe leave it alone or else say "are also to be visited". Hm... One man's right is another man's responsibility. Can it be that implementors of FileVisitor are more central to this documentation than callers of FileVisitor? Is that case any different from the one below? /** * Continue without visiting the siblings of this file or directory. * If returned from the {@link FileVisitor#preVisitDirectory * preVisitDirectory} method then the entries in the directory are also * skipped and the {@link FileVisitor#postVisitDirectory postVisitDirectory} * method is not invoked. */ SKIP_SIBLINGS; ------------- PR: https://git.openjdk.java.net/jdk/pull/5649 From alanb at openjdk.java.net Thu Sep 23 13:20:52 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 23 Sep 2021 13:20:52 GMT Subject: RFR: 8274195: Doc cleanup in java.nio.file In-Reply-To: <30z51skbLc0BEz9y7tclUMZOTsXHdPq722FuOnHzKkg=.73c78fd1-50c9-4b78-b4be-8e551671c21b@github.com> References: <1WJgg7gj3O0BZYuahzTC5thqGVt1qdTVSDuvFge6pMI=.d0db86d2-aad9-4e15-b9d1-b1a5cf019a48@github.com> <30z51skbLc0BEz9y7tclUMZOTsXHdPq722FuOnHzKkg=.73c78fd1-50c9-4b78-b4be-8e551671c21b@github.com> Message-ID: <9S7vvqOsZZTZyzSJp-TC6PC3ImLDy6p7ofKloVOnfbU=.16ab3224-821a-4586-b78c-d61770a7ee5b@github.com> On Thu, 23 Sep 2021 13:11:27 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/java/nio/file/FileVisitResult.java line 40: >> >>> 38: * Continue. If returned from the {@link FileVisitor#preVisitDirectory >>> 39: * preVisitDirectory} method then the entries in the directory are also >>> 40: * visited. >> >> "When returned" -> "If returned" is okay. >> Returning CONTINUE is an indication to the caller that the entries should be visited, maybe leave it alone or else say "are also to be visited". > > Hm... One man's right is another man's responsibility. Can it be that implementors of FileVisitor are more central to this documentation than callers of FileVisitor? Is that case any different from the one below? > > /** > * Continue without visiting the siblings of this file or directory. > * If returned from the {@link FileVisitor#preVisitDirectory > * preVisitDirectory} method then the entries in the directory are also > * skipped and the {@link FileVisitor#postVisitDirectory postVisitDirectory} > * method is not invoked. > */ > SKIP_SIBLINGS; I would prefer to drop this change from your patch, otherwise we will be forced to make changes to several areas to keep things consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/5649 From prappo at openjdk.java.net Thu Sep 23 13:28:17 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 23 Sep 2021 13:28:17 GMT Subject: RFR: 8274195: Doc cleanup in java.nio.file [v2] In-Reply-To: References: Message-ID: > Please review this trivial change triggered by reading the java.nio.file documentation for an unrelated code review. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Revert "Standardize wording in FileVisitResult constants" This reverts commit b080d6d1c1d12b839346c50c7184166499f8d08a. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5649/files - new: https://git.openjdk.java.net/jdk/pull/5649/files/b080d6d1..b0eaa8b3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5649&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5649&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5649.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5649/head:pull/5649 PR: https://git.openjdk.java.net/jdk/pull/5649 From alanb at openjdk.java.net Thu Sep 23 13:40:00 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 23 Sep 2021 13:40:00 GMT Subject: RFR: 8274195: Doc cleanup in java.nio.file [v2] In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 13:28:17 GMT, Pavel Rappo wrote: >> Please review this trivial change triggered by reading the java.nio.file documentation for an unrelated code review. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Standardize wording in FileVisitResult constants" > > This reverts commit b080d6d1c1d12b839346c50c7184166499f8d08a. Thanks for the limiting the changes in this update. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5649 From lancea at openjdk.java.net Thu Sep 23 14:24:54 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 23 Sep 2021 14:24:54 GMT Subject: RFR: 8274195: Doc cleanup in java.nio.file [v2] In-Reply-To: References: Message-ID: <5_G5VegcF2Yg5F4FMvUxAEK3IvbUiZzYEKwoe2vkFMc=.a4901d99-d61b-4c94-b11e-9089a741400d@github.com> On Thu, 23 Sep 2021 13:28:17 GMT, Pavel Rappo wrote: >> Please review this trivial change triggered by reading the java.nio.file documentation for an unrelated code review. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Standardize wording in FileVisitResult constants" > > This reverts commit b080d6d1c1d12b839346c50c7184166499f8d08a. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5649 From jboes at openjdk.java.net Thu Sep 23 15:14:14 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 23 Sep 2021 15:14:14 GMT Subject: RFR: 8274171: java/nio/file/Files/probeContentType/Basic.java failed on "Content type" mismatches Message-ID: This is a small follow-up to a recent update of the content-type.properties files [1]. The test fails on certain linux-x64 boxes, where the expected content type differs. Testing: tier 1-3, plus 1k runs of test in question [1] https://bugs.openjdk.java.net/browse/JDK-8273655 ------------- Commit messages: - initial change Changes: https://git.openjdk.java.net/jdk/pull/5656/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5656&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274171 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5656/head:pull/5656 PR: https://git.openjdk.java.net/jdk/pull/5656 From rriggs at openjdk.java.net Thu Sep 23 15:20:54 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 23 Sep 2021 15:20:54 GMT Subject: RFR: 8274171: java/nio/file/Files/probeContentType/Basic.java failed on "Content type" mismatches In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 14:47:00 GMT, Julia Boes wrote: > This is a small follow-up to a recent update of the content-type.properties files [1]. The test fails on certain linux-x64 boxes, where the expected content type differs. > > Testing: tier 1-3, plus 1k runs of test in question > > [1] https://bugs.openjdk.java.net/browse/JDK-8273655 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5656 From bpb at openjdk.java.net Thu Sep 23 15:57:55 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 15:57:55 GMT Subject: RFR: 8274175: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java still failed in timeout In-Reply-To: References: Message-ID: <5lS4nh97Nl1qOybInKEoWoQ8lPKuNoT_qNybEGOthsE=.ec944352-f23f-4729-ac90-7d1d5af675fc@github.com> On Thu, 23 Sep 2021 06:28:59 GMT, Alan Bateman wrote: > I hope this is enough. Likewise. ------------- PR: https://git.openjdk.java.net/jdk/pull/5642 From bpb at openjdk.java.net Thu Sep 23 16:00:56 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 16:00:56 GMT Subject: Integrated: 8274175: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java still failed in timeout In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 22:44:38 GMT, Brian Burkhalter wrote: > Test still fails in `othervm` mode; increase the timeout value. This pull request has now been integrated. Changeset: 1fdc6560 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/1fdc6560841f72b761756d935dd02e4bb2395ec6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8274175: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java still failed in timeout Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5642 From bpb at openjdk.java.net Thu Sep 23 16:09:50 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 16:09:50 GMT Subject: RFR: 8274171: java/nio/file/Files/probeContentType/Basic.java failed on "Content type" mismatches In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 14:47:00 GMT, Julia Boes wrote: > This is a small follow-up to a recent update of the content-type.properties files [1]. The test fails on certain linux-x64 boxes, where the expected content type differs. > > Testing: tier 1-3, plus 1k runs of test in question > > [1] https://bugs.openjdk.java.net/browse/JDK-8273655 Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5656 From bpb at openjdk.java.net Thu Sep 23 16:12:55 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 16:12:55 GMT Subject: RFR: 8274195: Doc cleanup in java.nio.file [v2] In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 13:28:17 GMT, Pavel Rappo wrote: >> Please review this trivial change triggered by reading the java.nio.file documentation for an unrelated code review. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Standardize wording in FileVisitResult constants" > > This reverts commit b080d6d1c1d12b839346c50c7184166499f8d08a. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5649 From bpb at openjdk.java.net Thu Sep 23 16:16:50 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 16:16:50 GMT Subject: RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v2] In-Reply-To: References: <6B7UxP42J7YqO3zy-oPaUY2MH-k2V9FzHL_zRa8dYvE=.adbcb921-4e73-4a8f-9a0a-660025746b38@github.com> Message-ID: On Tue, 21 Sep 2021 18:38:23 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273922: Add bug ID to @bug in test > > src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java line 62: > >> 60: StringBuilder sb = new StringBuilder(wp.getPathForWin32Calls()); >> 61: sb.setCharAt(sb.length() - name.length() - 1, ':'); >> 62: return sb.toString(); > > I suspect the right thing here is to parse "name" and maybe reject if it is not RELATIVE. Then concatenate and use createFromNormalizedPath(...) to create the WindowsPath. I expect it will be possible to reduce the number of conversions too although this isn't critical for now. Fixed in third commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/5594 From prappo at openjdk.java.net Thu Sep 23 16:22:54 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 23 Sep 2021 16:22:54 GMT Subject: Integrated: 8274195: Doc cleanup in java.nio.file In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 12:03:01 GMT, Pavel Rappo wrote: > Please review this trivial change triggered by reading the java.nio.file documentation for an unrelated code review. This pull request has now been integrated. Changeset: 5ffbe755 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/5ffbe7555771c67e28b5361d2a569f3dd858ff36 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8274195: Doc cleanup in java.nio.file Reviewed-by: alanb, lancea, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5649 From github.com+51889757+delvh at openjdk.java.net Thu Sep 23 22:22:53 2021 From: github.com+51889757+delvh at openjdk.java.net (delvh) Date: Thu, 23 Sep 2021 22:22:53 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 01:52:31 GMT, Brian Burkhalter wrote: > This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 115: > 113: @Override > 114: public byte[] readAllBytes() throws IOException { > 115: if (!(ch instanceof SeekableByteChannel)) I think Pattern matching can be used here to make `117` obsolete. So: Suggestion: if (!(ch instanceof SeekableByteChannel sbc)) src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 117: > 115: if (!(ch instanceof SeekableByteChannel)) > 116: return super.readAllBytes(); > 117: SeekableByteChannel sbc = (SeekableByteChannel)ch; Suggestion: src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 126: > 124: return super.readAllBytes(); > 125: > 126: if (size > (long) Integer.MAX_VALUE) { Suggestion: else if (size > (long) Integer.MAX_VALUE) { src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 138: > 136: int nread = 0; > 137: int n; > 138: for (;;) { Suggestion: while (true) { src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 164: > 162: if (len < 0) > 163: throw new IllegalArgumentException("len < 0"); > 164: if (len == 0) Suggestion: else if (len == 0) src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 167: > 165: return new byte[0]; > 166: > 167: if (!(ch instanceof SeekableByteChannel)) Suggestion: else if (!(ch instanceof SeekableByteChannel sbc)) src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 169: > 167: if (!(ch instanceof SeekableByteChannel)) > 168: return super.readAllBytes(); > 169: SeekableByteChannel sbc = (SeekableByteChannel)ch; Suggestion: src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 186: > 184: do { > 185: n = read(buf, nread, remaining); > 186: if (n > 0 ) { Formatting? Suggestion: if (n > 0) { ------------- PR: https://git.openjdk.java.net/jdk/pull/5645 From bpb at openjdk.java.net Thu Sep 23 23:45:26 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 23:45:26 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v2] In-Reply-To: References: Message-ID: > This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8268435: Use instanceof pattern matching ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5645/files - new: https://git.openjdk.java.net/jdk/pull/5645/files/11baa379..ca188f03 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5645&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5645&range=00-01 Stats: 21 lines in 2 files changed: 5 ins; 5 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5645/head:pull/5645 PR: https://git.openjdk.java.net/jdk/pull/5645 From bpb at openjdk.java.net Thu Sep 23 23:45:35 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 23 Sep 2021 23:45:35 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v2] In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 22:12:52 GMT, delvh wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8268435: Use instanceof pattern matching > > src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 115: > >> 113: @Override >> 114: public byte[] readAllBytes() throws IOException { >> 115: if (!(ch instanceof SeekableByteChannel)) > > I think Pattern matching can be used here to make `117` obsolete. So: > Suggestion: > > if (!(ch instanceof SeekableByteChannel sbc)) Fixed. > src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 117: > >> 115: if (!(ch instanceof SeekableByteChannel)) >> 116: return super.readAllBytes(); >> 117: SeekableByteChannel sbc = (SeekableByteChannel)ch; > > Suggestion: Fixed. > src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 126: > >> 124: return super.readAllBytes(); >> 125: >> 126: if (size > (long) Integer.MAX_VALUE) { > > Suggestion: > > else if (size > (long) Integer.MAX_VALUE) { It is common practice in the libraries to use multiple `if` statements to return as soon as feasible. > src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 138: > >> 136: int nread = 0; >> 137: int n; >> 138: for (;;) { > > Suggestion: > > while (true) { The use of `for(;;)` is common; not changed. > src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 164: > >> 162: if (len < 0) >> 163: throw new IllegalArgumentException("len < 0"); >> 164: if (len == 0) > > Suggestion: > > else if (len == 0) Same comment as above. > src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 167: > >> 165: return new byte[0]; >> 166: >> 167: if (!(ch instanceof SeekableByteChannel)) > > Suggestion: > > else if (!(ch instanceof SeekableByteChannel sbc)) Fixed. > src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 169: > >> 167: if (!(ch instanceof SeekableByteChannel)) >> 168: return super.readAllBytes(); >> 169: SeekableByteChannel sbc = (SeekableByteChannel)ch; > > Suggestion: Fixed. > src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 186: > >> 184: do { >> 185: n = read(buf, nread, remaining); >> 186: if (n > 0 ) { > > Formatting? > Suggestion: > > if (n > 0) { Fixed here and in `FileInputStream`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5645 From jboes at openjdk.java.net Fri Sep 24 08:13:56 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 24 Sep 2021 08:13:56 GMT Subject: Integrated: 8274171: java/nio/file/Files/probeContentType/Basic.java failed on "Content type" mismatches In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 14:47:00 GMT, Julia Boes wrote: > This is a small follow-up to a recent update of the content-type.properties files [1]. The test fails on certain linux-x64 boxes, where the expected content type differs. > > Testing: tier 1-3, plus 1k runs of test in question > > [1] https://bugs.openjdk.java.net/browse/JDK-8273655 This pull request has now been integrated. Changeset: bb74ae87 Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/bb74ae87abee0fb550e4138242919ec791f7791c Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8274171: java/nio/file/Files/probeContentType/Basic.java failed on "Content type" mismatches Reviewed-by: rriggs, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5656 From alanb at openjdk.java.net Fri Sep 24 12:44:58 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 24 Sep 2021 12:44:58 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v2] In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 23:45:26 GMT, Brian Burkhalter wrote: >> This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8268435: Use instanceof pattern matching The overrides of readAllBytes and readNBytes in ChannelInputStream look okay. I don't have time to spend on the test right now but I wonder if we should create a new TestNG with simple tests rather than a expanding Basic.testNewInputStream with lots of cases. I can't immediately see if we have tests for an empty file, position at EOF, files > 2GB, and other cases that we might want to add. ------------- PR: https://git.openjdk.java.net/jdk/pull/5645 From redestad at openjdk.java.net Fri Sep 24 16:04:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 24 Sep 2021 16:04:08 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. The current version (cef05f4) copies the ISO_8859_1.implEncodeISOArray intrinsic and adapts it to work on ASCII encoding, which makes the UTF_8$Encoder perform on par with (or outperform) encoding from a String. Using microbenchmarks provided by @carterkozak here: https://github.com/carterkozak/stringbuilder-encoding-performance Baseline: Benchmark (charsetName) (message) (timesToAppend) Mode Cnt Score Error Units EncoderBenchmarks.charsetEncoder UTF-8 This is a simple ASCII message 3 avgt 8 270.237 ? 10.504 ns/op EncoderBenchmarks.charsetEncoder UTF-8 This is a message with unicode ?? 3 avgt 8 568.353 ? 2.331 ns/op EncoderBenchmarks.charsetEncoderWithAllocation UTF-8 This is a simple ASCII message 3 avgt 8 324.889 ? 17.466 ns/op EncoderBenchmarks.charsetEncoderWithAllocation UTF-8 This is a message with unicode ?? 3 avgt 8 633.720 ? 22.703 ns/op EncoderBenchmarks.charsetEncoderWithAllocationWrappingBuilder UTF-8 This is a simple ASCII message 3 avgt 8 1132.436 ? 30.661 ns/op EncoderBenchmarks.charsetEncoderWithAllocationWrappingBuilder UTF-8 This is a message with unicode ?? 3 avgt 8 1379.207 ? 66.982 ns/op EncoderBenchmarks.toStringGetBytes UTF-8 This is a simple ASCII message 3 avgt 8 91.253 ? 3.848 ns/op EncoderBenchmarks.toStringGetBytes UTF-8 This is a message with unicode ?? 3 avgt 8 519.489 ? 12.516 ns/op Patch: Benchmark (charsetName) (message) (timesToAppend) Mode Cnt Score Error Units EncoderBenchmarks.charsetEncoder UTF-8 This is a simple ASCII message 3 avgt 4 82.535 ? 20.310 ns/op EncoderBenchmarks.charsetEncoder UTF-8 This is a message with unicode ?? 3 avgt 4 522.679 ? 13.456 ns/op EncoderBenchmarks.charsetEncoderWithAllocation UTF-8 This is a simple ASCII message 3 avgt 4 127.831 ? 32.612 ns/op EncoderBenchmarks.charsetEncoderWithAllocation UTF-8 This is a message with unicode ?? 3 avgt 4 549.343 ? 59.899 ns/op EncoderBenchmarks.charsetEncoderWithAllocationWrappingBuilder UTF-8 This is a simple ASCII message 3 avgt 4 1182.835 ? 153.735 ns/op EncoderBenchmarks.charsetEncoderWithAllocationWrappingBuilder UTF-8 This is a message with unicode ?? 3 avgt 4 1416.407 ? 130.551 ns/op EncoderBenchmarks.toStringGetBytes UTF-8 This is a simple ASCII message 3 avgt 4 97.770 ? 15.742 ns/op EncoderBenchmarks.toStringGetBytes UTF-8 This is a message with unicode ?? 3 avgt 4 516.351 ? 58.580 ns/op This can probably be simplified further, say by adding a flag to the intrinsic of whether we're encoding ASCII only or ISO-8859-1. It also needs to be implemented and tested on all architectures. (edit: accidentally edit rather than quote-reply, restored original comment) On the JDK-included `CharsetEncodeDecode.encode` microbenchmark, I get these numbers in the baseline (18-b09): Benchmark (size) (type) Mode Cnt Score Error Units CharsetEncodeDecode.encode 16384 UTF-8 avgt 30 39.962 ? 1.703 us/op CharsetEncodeDecode.encode 16384 BIG5 avgt 30 153.282 ? 4.521 us/op CharsetEncodeDecode.encode 16384 ISO-8859-15 avgt 30 192.040 ? 4.543 us/op CharsetEncodeDecode.encode 16384 ASCII avgt 30 40.051 ? 1.210 us/op CharsetEncodeDecode.encode 16384 UTF-16 avgt 30 302.815 ? 9.490 us/op With the proposed patch: Benchmark (size) (type) Mode Cnt Score Error Units CharsetEncodeDecode.encode 16384 UTF-8 avgt 30 4.081 ? 0.182 us/op CharsetEncodeDecode.encode 16384 BIG5 avgt 30 150.374 ? 3.579 us/op CharsetEncodeDecode.encode 16384 ISO-8859-15 avgt 30 4.010 ? 0.179 us/op CharsetEncodeDecode.encode 16384 ASCII avgt 30 3.961 ? 0.176 us/op CharsetEncodeDecode.encode 16384 UTF-16 avgt 30 302.235 ? 11.395 us/op That is: on my system encoding 16K char ASCII data is 10x faster for UTF-8 and ASCII, and roughly 48x faster for ASCII-compatible charsets like ISO-8859-15. On 3rd party microbenchmarks we can assert that performance for non-ASCII input either doesn't change, or improves when messages have an ASCII prefix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Fri Sep 24 16:04:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 24 Sep 2021 16:04:08 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 Message-ID: This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. ------------- Commit messages: - Freshen up CharsetEncodeDecode micro (still only tests ASCII), optimize ASCII-compatible SingleByte (e.g. ISO-8859-15) - Add @bug id to test - Move and adapt defunct Test6896617 test to test more Charsets without using internal APIs; remove adhoc performance tests - Exclude encodeAsciiArray intrinsic on all non-X86 platforms - Fix indentation - Remove EncodeAsciiArray node and instead extend EncodeISOArray with an is_ascii predicate - Merge MacroAssembler methods - Implement intrinsified ASCII fast-path by copying and adapting encodeISOArray intrinsic (currently x86 only) - Enhance UTF_8.Encoder by using StringUTF16.compress for ASCII Changes: https://git.openjdk.java.net/jdk/pull/5621/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274242 Stats: 763 lines in 20 files changed: 375 ins; 355 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Fri Sep 24 16:04:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 24 Sep 2021 16:04:08 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 00:03:55 GMT, Claes Redestad wrote: > This can probably be simplified further, say by adding a flag to the intrinsic of whether we're encoding ASCII only or ISO-8859-1. Done: Removed the addition of a new C2 Node, merged the macro assembler encode_iso_array and encode_ascii_array and added a predicate to select the behavior. > It also needs to be implemented and tested on all architectures. Implementing this on other hardware is Future Work. The non-x86 intrinsics for implEncodeISOArray all seem to use clever tricks rather than a simple mask that can be easily switched from detecting non-latin-1(0xFF00) to detecting ASCII (0xFF80). Clever tricks make it rather challenging to extend this like I could easily do in the x86 code (most all assembler is foreign to me) ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From naoto at openjdk.java.net Fri Sep 24 20:42:55 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 24 Sep 2021 20:42:55 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. core library part of the changes looks good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5621 From bpb at openjdk.java.net Fri Sep 24 22:36:29 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 24 Sep 2021 22:36:29 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v3] In-Reply-To: References: Message-ID: > This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8268435: Create a TestNG test based on the previous changes to Basic.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5645/files - new: https://git.openjdk.java.net/jdk/pull/5645/files/ca188f03..4ad8e2ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5645&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5645&range=01-02 Stats: 214 lines in 2 files changed: 155 ins; 43 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5645/head:pull/5645 PR: https://git.openjdk.java.net/jdk/pull/5645 From bpb at openjdk.java.net Fri Sep 24 22:36:30 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 24 Sep 2021 22:36:30 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v2] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 12:41:56 GMT, Alan Bateman wrote: > The overrides of readAllBytes and readNBytes in ChannelInputStream look okay. > I don't have time to spend on the test right now but I wonder if we should create a new TestNG with simple tests rather than a expanding Basic.testNewInputStream with lots of cases. I can't immediately see if we have tests for an empty file, position at EOF, files > 2GB, and other cases that we might want to add. The third commit, version 02, adds a TestNG test which replaces the previously expanded `Basic.testNewInputStream()`. The new test checks the expected behavior in normal operation, for a file > 2 GB, for an empty file, and for a file at EOF. ------------- PR: https://git.openjdk.java.net/jdk/pull/5645 From sviswanathan at openjdk.java.net Fri Sep 24 23:19:17 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 24 Sep 2021 23:19:17 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. x86 part of changes look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From jpai at openjdk.java.net Sat Sep 25 06:59:14 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 25 Sep 2021 06:59:14 GMT Subject: RFR: 8274314: Typo in WatchService#poll(long timeout, TimeUnit unit) javadoc Message-ID: Could I please get a review for this trivial fix in the javadoc of WatchService#poll(long timeout, TimeUnit unit)? ------------- Commit messages: - 8274314: Typo in WatchService#poll(long timeout, TimeUnit unit) javadoc Changes: https://git.openjdk.java.net/jdk/pull/5692/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5692&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274314 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5692.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5692/head:pull/5692 PR: https://git.openjdk.java.net/jdk/pull/5692 From alanb at openjdk.java.net Sat Sep 25 06:59:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 25 Sep 2021 06:59:14 GMT Subject: RFR: 8274314: Typo in WatchService#poll(long timeout, TimeUnit unit) javadoc In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 06:30:21 GMT, Jaikiran Pai wrote: > Could I please get a review for this trivial fix in the javadoc of WatchService#poll(long timeout, TimeUnit unit)? Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5692 From jpai at openjdk.java.net Sat Sep 25 07:12:04 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 25 Sep 2021 07:12:04 GMT Subject: RFR: 8174819: java/nio/file/WatchService/LotsOfEvents.java fails intermittently Message-ID: Can I please get a review for this test-only change that aims to fix an intermittent failure in `LotsOfEvents` testcase? As noted by Alan in the JBS issue https://bugs.openjdk.java.net/browse/JDK-8174819, the test failure is likely due to the relatively smaller poll timeout that it currently uses. IMO, this guess is proved right by the diagnostic logs that the test is currently printing, as I note in my comment in that JBS issue. The commit in this PR increases the 2 second timeout that was used (only) in the loop to 15 seconds to make it match the poll timeout that is used outside the loop. IMO, this increase in timeout shouldn't really slow down the test, since this is the "max amount of time to wait". The 13 second additional wait would ideally only show for the "last" poll where there are no more events. Additionally, this commit also adds a few more diagnostic logs for future use, if this test fails in future. Do note that there's also a `testModifyEventsQueuing` test method which too uses a 2 second timeout in a loop. I haven't touched/changed that timeout, since that test hasn't yet failed (perhaps because the number of events generated there are just 100 as against 1024 in this `testOverflowEvent` test). If at all that other test fails any time in future, we can perhaps consider increasing the timeout there too. ------------- Commit messages: - 8174819: java/nio/file/WatchService/LotsOfEvents.java fails intermittently Changes: https://git.openjdk.java.net/jdk/pull/5693/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5693&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8174819 Stats: 14 lines in 1 file changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5693.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5693/head:pull/5693 PR: https://git.openjdk.java.net/jdk/pull/5693 From lancea at openjdk.java.net Sat Sep 25 10:41:52 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 25 Sep 2021 10:41:52 GMT Subject: RFR: 8274314: Typo in WatchService#poll(long timeout, TimeUnit unit) javadoc In-Reply-To: References: Message-ID: <1bYNHpnuzIbKW9FCzP0rZA65LInOqeuHdHgnRISvNbQ=.4f3fe3a2-2529-487e-a8b1-99a8abfe5f86@github.com> On Sat, 25 Sep 2021 06:30:21 GMT, Jaikiran Pai wrote: > Could I please get a review for this trivial fix in the javadoc of WatchService#poll(long timeout, TimeUnit unit)? Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5692 From alanb at openjdk.java.net Sat Sep 25 11:51:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 25 Sep 2021 11:51:55 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v3] In-Reply-To: References: Message-ID: <7Kcyjr6nrjs-GLNiORZGiLOguRX_z42RANfXlW5yBrE=.d974752c-b254-4f09-959f-059d86d2c55b@github.com> On Fri, 24 Sep 2021 22:36:29 GMT, Brian Burkhalter wrote: >> This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8268435: Create a TestNG test based on the previous changes to Basic.java Changes requested by alanb (Reviewer). test/jdk/sun/nio/ch/ChannelInputStream.java line 55: > 53: import org.testng.annotations.Test; > 54: > 55: public class ChannelInputStream { The tests for Channels API are in java/nio/channels/Channels and we should keep them in tree if possible. If test is focused on readXXXBytes then we should come up with a better name for the test, maybe "ReadXBytesTest" rather than "ChannelInputStream". test/jdk/sun/nio/ch/ChannelInputStream.java line 106: > 104: } finally { > 105: file.delete(); > 106: } It might be easy to maintain if we split this up so there are separate tests for empty files, OOME, etc. Are you planning to update the test cover the case that the initial position is > 0? Has the setup been copied from an older test, I'm wondering why it needs to use File and FileChannel::getChannel as you should be able to use FileChannel.open. test/jdk/sun/nio/ch/ChannelInputStream.java line 141: > 139: } finally { > 140: file.delete(); > 141: } It might be easy to maintain if this one were split up too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5645 From jpai at openjdk.java.net Sat Sep 25 12:47:57 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 25 Sep 2021 12:47:57 GMT Subject: RFR: 8274314: Typo in WatchService#poll(long timeout, TimeUnit unit) javadoc In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 06:30:21 GMT, Jaikiran Pai wrote: > Could I please get a review for this trivial fix in the javadoc of WatchService#poll(long timeout, TimeUnit unit)? Thank you Alan and Lance for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/5692 From jpai at openjdk.java.net Sat Sep 25 12:47:58 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 25 Sep 2021 12:47:58 GMT Subject: Integrated: 8274314: Typo in WatchService#poll(long timeout, TimeUnit unit) javadoc In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 06:30:21 GMT, Jaikiran Pai wrote: > Could I please get a review for this trivial fix in the javadoc of WatchService#poll(long timeout, TimeUnit unit)? This pull request has now been integrated. Changeset: 8c122af6 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/8c122af6d8c3028dc0c49d7f3d48471faa3ceaa8 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8274314: Typo in WatchService#poll(long timeout, TimeUnit unit) javadoc Reviewed-by: alanb, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5692 From alanb at openjdk.java.net Sun Sep 26 08:28:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 26 Sep 2021 08:28:07 GMT Subject: RFR: 8174819: java/nio/file/WatchService/LotsOfEvents.java fails intermittently In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 07:02:12 GMT, Jaikiran Pai wrote: > Can I please get a review for this test-only change that aims to fix an intermittent failure in `LotsOfEvents` testcase? > > As noted by Alan in the JBS issue https://bugs.openjdk.java.net/browse/JDK-8174819, the test failure is likely due to the relatively smaller poll timeout that it currently uses. IMO, this guess is proved right by the diagnostic logs that the test is currently printing, as I note in my comment in that JBS issue. > > The commit in this PR increases the 2 second timeout that was used (only) in the loop to 15 seconds to make it match the poll timeout that is used outside the loop. IMO, this increase in timeout shouldn't really slow down the test, since this is the "max amount of time to wait". The 13 second additional wait would ideally only show for the "last" poll where there are no more events. > > Additionally, this commit also adds a few more diagnostic logs for future use, if this test fails in future. > > Do note that there's also a `testModifyEventsQueuing` test method which too uses a 2 second timeout in a loop. I haven't touched/changed that timeout, since that test hasn't yet failed (perhaps because the number of events generated there are just 100 as against 1024 in this `testOverflowEvent` test). If at all that other test fails any time in future, we can perhaps consider increasing the timeout there too. test/jdk/java/nio/file/WatchService/LotsOfEvents.java line 111: > 109: while (key != null) { > 110: List> events = key.pollEvents(); > 111: System.out.println("Polling retrieved " + events.size() + " events"); Minor nit, this should be "event(s)" to avoid "1 events". test/jdk/java/nio/file/WatchService/LotsOfEvents.java line 129: > 127: if (!key.reset()) > 128: throw new RuntimeException("Key is no longer valid"); > 129: key = watcher.poll(15, TimeUnit.SECONDS); Seem very long but might be okay. test/jdk/java/nio/file/WatchService/LotsOfEvents.java line 151: > 149: Map countPerEventType = events.stream() > 150: .collect(Collectors.groupingBy(WatchEvent::kind, Collectors.counting())); > 151: System.err.println("After extra polling, found:"); I assume the trace message at L151 is not needed. L146 will print the count and this will be followed by the count of each kind. ------------- PR: https://git.openjdk.java.net/jdk/pull/5693 From jpai at openjdk.java.net Sun Sep 26 12:31:33 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 26 Sep 2021 12:31:33 GMT Subject: RFR: 8174819: java/nio/file/WatchService/LotsOfEvents.java fails intermittently [v2] In-Reply-To: References: Message-ID: > Can I please get a review for this test-only change that aims to fix an intermittent failure in `LotsOfEvents` testcase? > > As noted by Alan in the JBS issue https://bugs.openjdk.java.net/browse/JDK-8174819, the test failure is likely due to the relatively smaller poll timeout that it currently uses. IMO, this guess is proved right by the diagnostic logs that the test is currently printing, as I note in my comment in that JBS issue. > > The commit in this PR increases the 2 second timeout that was used (only) in the loop to 15 seconds to make it match the poll timeout that is used outside the loop. IMO, this increase in timeout shouldn't really slow down the test, since this is the "max amount of time to wait". The 13 second additional wait would ideally only show for the "last" poll where there are no more events. > > Additionally, this commit also adds a few more diagnostic logs for future use, if this test fails in future. > > Do note that there's also a `testModifyEventsQueuing` test method which too uses a 2 second timeout in a loop. I haven't touched/changed that timeout, since that test hasn't yet failed (perhaps because the number of events generated there are just 100 as against 1024 in this `testOverflowEvent` test). If at all that other test fails any time in future, we can perhaps consider increasing the timeout there too. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5693/files - new: https://git.openjdk.java.net/jdk/pull/5693/files/c2f071c3..9efe5656 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5693&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5693&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5693.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5693/head:pull/5693 PR: https://git.openjdk.java.net/jdk/pull/5693 From jpai at openjdk.java.net Sun Sep 26 12:31:36 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 26 Sep 2021 12:31:36 GMT Subject: RFR: 8174819: java/nio/file/WatchService/LotsOfEvents.java fails intermittently [v2] In-Reply-To: References: Message-ID: On Sun, 26 Sep 2021 08:21:19 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > test/jdk/java/nio/file/WatchService/LotsOfEvents.java line 111: > >> 109: while (key != null) { >> 110: List> events = key.pollEvents(); >> 111: System.out.println("Polling retrieved " + events.size() + " events"); > > Minor nit, this should be "event(s)" to avoid "1 events". Done. Addressed in latest version of PR. > test/jdk/java/nio/file/WatchService/LotsOfEvents.java line 151: > >> 149: Map countPerEventType = events.stream() >> 150: .collect(Collectors.groupingBy(WatchEvent::kind, Collectors.counting())); >> 151: System.err.println("After extra polling, found:"); > > I assume the trace message at L151 is not needed. L146 will print the count and this will be followed by the count of each kind. Done. Removed the (previous) L151 log message that was newly introduced in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5693 From github.com+1701815+mkarg at openjdk.java.net Sun Sep 26 13:34:31 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 26 Sep 2021 13:34:31 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v3] In-Reply-To: References: Message-ID: > Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. > > This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. > > *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Comment for each DataProvider/Test Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5421/files - new: https://git.openjdk.java.net/jdk/pull/5421/files/b37ad6b3..b08c5a0a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=01-02 Stats: 21 lines in 1 file changed: 17 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5421/head:pull/5421 PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Sun Sep 26 13:34:33 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 26 Sep 2021 13:34:33 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v2] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 14:13:14 GMT, Lance Andersen wrote: >> Markus KARG has updated the pull request incrementally with one additional commit since the last revision: >> >> Using assert* methods instead of fail() and expectedExceptions >> >> Signed-off-by: Markus Karg > >> > I would add a comment for for each DataProvider/Test to give future maintainers an overview of the intent of the methods >> >> I support the general idea of making things more comprehensible, but I will abstain from adding comments in _this_ PR due to three reasons: >> >> * This PR _solely_ has the target of technically introducing **TestNG** and I really do not want to mix concerns like technical merits with documental merits. >> * The current PR is a blocker in the _critical path_ of other, higher prioritized PRs. We should try not to slow it down _unnecessarily_. >> * I dislike code comments and would instead prefer to turn this source code into **BDD** style, i. e. changing the test name into "shouldDoThisInThatCase" style and introducing "given", "when" and "then" sections inside the tests. As this source code is a copy of two other original files, I will do it for all three files in one shot to keep their inherent relationship. >> >> So in the best sense of KISS, SoC and "release early, release often", it makes sense that I will create an (or mutiple) explicit, subsequent PR(s) for introducing BDD instead of adding code comments in the current (slow and big) PR. > > We are going to have to agree to disagree here. Comments are/should be part of the development process including for tests. There is no reason to create additional issues or new PRs given the tests is already being modified. > >> > I would add a comment for for each DataProvider/Test to give future maintainers an overview of the intent of the methods >> >> I support the general idea of making things more comprehensible, but I will abstain from adding comments in _this_ PR due to three reasons: >> >> * This PR _solely_ has the target of technically introducing **TestNG** and I really do not want to mix concerns like technical merits with documental merits. >> * The current PR is a blocker in the _critical path_ of other, higher prioritized PRs. We should try not to slow it down _unnecessarily_. >> * I dislike code comments and would instead prefer to turn this source code into **BDD** style, i. e. changing the test name into "shouldDoThisInThatCase" style and introducing "given", "when" and "then" sections inside the tests. As this source code is a copy of two other original files, I will do it for all three files in one shot to keep their inherent relationship. >> >> So in the best sense of KISS, SoC and "release early, release often", it makes sense that I will create an (or mutiple) explicit, subsequent PR(s) for introducing BDD instead of adding code comments in the current (slow and big) PR. > > We are going to agree to disagree on this. There is no reason to create additional issues/PRs for improving the readability/documentation. Comments do not have to be extensive but enough to introduce the intent of the test. Now is the right time to add comments given the test is being updated. > > As we evolve/maintain OpenJDK, we want to keep maintainability for current and future developers in mind. Adding documentation/comments while we are updating/adding to the project will help in this endeavor (and I know it would have helped me while navigating areas of the codebase I was less familiar with). @LanceAndersen requested: > I would add a comment for for each DataProvider/Test to give future maintainers an overview of the intent of the methods Done by https://github.com/openjdk/jdk/pull/5421/commits/b08c5a0a545bad9168ac0afae3d46551658f6ee1. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Sun Sep 26 13:44:31 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 26 Sep 2021 13:44:31 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v4] In-Reply-To: References: Message-ID: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> > Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. > > This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. > > *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Comment for checkTransferredContents Signed-off-by: Markus Karg ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5421/files - new: https://git.openjdk.java.net/jdk/pull/5421/files/b08c5a0a..0f056984 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5421&range=02-03 Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5421/head:pull/5421 PR: https://git.openjdk.java.net/jdk/pull/5421 From github.com+1701815+mkarg at openjdk.java.net Sun Sep 26 15:30:59 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 26 Sep 2021 15:30:59 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v2] In-Reply-To: <9XPO9YcAPkKHDMDdoUGrizIaHcrmLRa-TBoyMJemES8=.2410586d-c80d-46a0-a525-746ab864f234@github.com> References: <9XPO9YcAPkKHDMDdoUGrizIaHcrmLRa-TBoyMJemES8=.2410586d-c80d-46a0-a525-746ab864f234@github.com> Message-ID: On Mon, 13 Sep 2021 09:10:13 GMT, Alan Bateman wrote: >>> > * I dislike code comments and would instead prefer to turn this source code into **BDD** style, i. e. changing the test name into "shouldDoThisInThatCase" style and introducing "given", "when" and "then" sections inside the tests. As this source code is a copy of two other original files, I will do it for all three files in one shot to keep their inherent relationship. >>> > >>> > So in the best sense of KISS, SoC and "release early, release often", it makes sense that I will create an (or mutiple) explicit, subsequent PR(s) for introducing BDD instead of adding code comments in the current (slow and big) PR. >>> >>> We are going to agree to disagree on this. There is no reason to create additional issues/PRs for improving the readability/documentation. Comments do not have to be extensive but enough to introduce the intent of the test. Now is the right time to add comments given the test is being updated. >>> >>> As we evolve/maintain OpenJDK, we want to keep maintainability for current and future developers in mind. Adding documentation/comments while we are updating/adding to the project will help in this endeavor (and I know it would have helped me while navigating areas of the codebase I was less familiar with). >> >> So this effectively means that you rather want to *prevent* this PR, which was demanded by @AlanBateman, and rather want to live with the test *as-is*, unless I add more comments that are *totally unrelated* with this PR? So what if I just don't agree here? Then you will never get *either* the comments *nor* will Alan get TestNG. >> >> BTW, if some day someone needs to undo my PR, then all the BDD changes will be gone, too. This is ridiculuous. Due to the mass of changes BDD imposes, this **must** be separate PRs to prevent that. >> >> And a final word: Alain and Brian both agreed that the original test is fine, maintainable and comprehensive. If you take a minute to read the actual code being tested, you will notice that the test already is self-explanatory already without any comments. > >> * I dislike code comments and would instead prefer to turn this source code into **BDD** style, i. e. changing the test name into "shouldDoThisInThatCase" style and introducing "given", "when" and "then" sections inside the tests. As this source code is a copy of two other original files, I will do it for all three files in one shot to keep their inherent relationship. > > Ugh, please no. As Lance said, we need the source and tests to be as easy to maintain as possible. In this case it would be helpful to have comments on testStreamContents and checkTransferredContents so that it's very quick for someone to know what the test is trying to when it fails (in this area, most of the effort on tests is spent chasing intermittent test failures). @AlanBateman wrote: > In this case it would be helpful to have comments on testStreamContents and checkTransferredContents so that it's very quick for someone to know what the test is trying to when it fails (in this area, most of the effort on tests is spent chasing intermittent test failures). Done by https://github.com/openjdk/jdk/pull/5421/commits/0f0569843faa7c319bb03990eb922406ac78e626. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From alanb at openjdk.java.net Mon Sep 27 05:17:05 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 27 Sep 2021 05:17:05 GMT Subject: RFR: 8174819: java/nio/file/WatchService/LotsOfEvents.java fails intermittently [v2] In-Reply-To: References: Message-ID: On Sun, 26 Sep 2021 12:31:33 GMT, Jaikiran Pai wrote: >> Can I please get a review for this test-only change that aims to fix an intermittent failure in `LotsOfEvents` testcase? >> >> As noted by Alan in the JBS issue https://bugs.openjdk.java.net/browse/JDK-8174819, the test failure is likely due to the relatively smaller poll timeout that it currently uses. IMO, this guess is proved right by the diagnostic logs that the test is currently printing, as I note in my comment in that JBS issue. >> >> The commit in this PR increases the 2 second timeout that was used (only) in the loop to 15 seconds to make it match the poll timeout that is used outside the loop. IMO, this increase in timeout shouldn't really slow down the test, since this is the "max amount of time to wait". The 13 second additional wait would ideally only show for the "last" poll where there are no more events. >> >> Additionally, this commit also adds a few more diagnostic logs for future use, if this test fails in future. >> >> Do note that there's also a `testModifyEventsQueuing` test method which too uses a 2 second timeout in a loop. I haven't touched/changed that timeout, since that test hasn't yet failed (perhaps because the number of events generated there are just 100 as against 1024 in this `testOverflowEvent` test). If at all that other test fails any time in future, we can perhaps consider increasing the timeout there too. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5693 From thartmann at openjdk.java.net Mon Sep 27 06:40:06 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 27 Sep 2021 06:40:06 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: <5lVTU7su0xmkfNlex-Pv_yoeuJpnoCyalI42oLSjGzg=.54d143bc-ede4-4ec8-a257-1538f43ea632@github.com> On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Very nice. The changes look good to me, just added some minor comments. Should we remove the "iso" part from the method/class names? src/hotspot/cpu/x86/x86_32.ad line 12218: > 12216: instruct encode_ascii_array(eSIRegP src, eDIRegP dst, eDXRegI len, > 12217: regD tmp1, regD tmp2, regD tmp3, regD tmp4, > 12218: eCXRegI tmp5, eAXRegI result, eFlagsReg cr) %{ Indentation is wrong. src/hotspot/cpu/x86/x86_32.ad line 12223: > 12221: effect(TEMP tmp1, TEMP tmp2, TEMP tmp3, TEMP tmp4, USE_KILL src, USE_KILL dst, USE_KILL len, KILL tmp5, KILL cr); > 12222: > 12223: format %{ "Encode array $src,$dst,$len -> $result // KILL ECX, EDX, $tmp1, $tmp2, $tmp3, $tmp4, ESI, EDI " %} You might want to change the opto assembly comment to "Encode ascii array" (and to "Encode iso array" above). Same on 64-bit. src/hotspot/share/opto/intrinsicnode.hpp line 171: > 169: > 170: //------------------------------EncodeISOArray-------------------------------- > 171: // encode char[] to byte[] in ISO_8859_1 Comment should be adjusted to `... in ISO_8859_1 or ASCII`. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5621 From simonis at openjdk.java.net Mon Sep 27 09:38:01 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 27 Sep 2021 09:38:01 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. src/hotspot/share/opto/c2compiler.cpp line 222: > 220: #if !defined(X86) > 221: return false; // not yet implemented > 222: #endif It might be a little more work, but I think it's cleaner to move the decision whether the intrinisc is supported into the Matcher like for most other intrinsics and keep this code here platform independent. Otherwise we will get an increasing cascade of ifdefs as people start implementing this for other platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Mon Sep 27 11:41:34 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 27 Sep 2021 11:41:34 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v2] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Tobias review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/8edc228f..12ab6ff5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=00-01 Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Mon Sep 27 12:03:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 27 Sep 2021 12:03:08 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v2] In-Reply-To: <5lVTU7su0xmkfNlex-Pv_yoeuJpnoCyalI42oLSjGzg=.54d143bc-ede4-4ec8-a257-1538f43ea632@github.com> References: <5lVTU7su0xmkfNlex-Pv_yoeuJpnoCyalI42oLSjGzg=.54d143bc-ede4-4ec8-a257-1538f43ea632@github.com> Message-ID: On Mon, 27 Sep 2021 06:36:50 GMT, Tobias Hartmann wrote: > Should we remove the "iso" part from the method/class names? I'm open to suggestions, but I've not been able to think of anything better. `encodeISOOrASCII` doesn't seem helpful and since ASCII is a subset of the ISO-8859-1 encoding referred to by the "iso" moniker then the ASCII-only variant is technically encoding chars to valid ISO-8859-1. ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Mon Sep 27 12:12:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 27 Sep 2021 12:12:05 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v3] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add Matcher predicate to avoid changing shared code as non-x86 platforms implements support for the _encodeAsciiArray intrinsic ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/12ab6ff5..9800a99a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=01-02 Stats: 17 lines in 6 files changed: 14 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Mon Sep 27 12:14:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 27 Sep 2021 12:14:05 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v3] In-Reply-To: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> References: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> Message-ID: On Mon, 27 Sep 2021 09:34:21 GMT, Volker Simonis wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Add Matcher predicate to avoid changing shared code as non-x86 platforms implements support for the _encodeAsciiArray intrinsic > > src/hotspot/share/opto/c2compiler.cpp line 222: > >> 220: #if !defined(X86) >> 221: return false; // not yet implemented >> 222: #endif > > It might be a little more work, but I think it's cleaner to move the decision whether the intrinisc is supported into the Matcher like for most other intrinsics and keep this code here platform independent. Otherwise we will get an increasing cascade of ifdefs as people start implementing this for other platforms. Not too much work. I recently introduced platform-specific `matcher_*.hpp` files, so since then adding a boolean constant is easy (no need to muck with the .ad files). ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From thartmann at openjdk.java.net Mon Sep 27 12:30:52 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 27 Sep 2021 12:30:52 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v3] In-Reply-To: References: <5lVTU7su0xmkfNlex-Pv_yoeuJpnoCyalI42oLSjGzg=.54d143bc-ede4-4ec8-a257-1538f43ea632@github.com> Message-ID: On Mon, 27 Sep 2021 11:59:54 GMT, Claes Redestad wrote: > > Should we remove the "iso" part from the method/class names? > > I'm open to suggestions, but I've not been able to think of anything better. `encodeISOOrASCII` doesn't seem helpful and since ASCII is a subset of the ISO-8859-1 encoding referred to by the "iso" moniker then the ASCII-only variant is technically encoding chars to valid ISO-8859-1. Okay, that's fine with me. ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From jpai at openjdk.java.net Tue Sep 28 04:57:56 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 28 Sep 2021 04:57:56 GMT Subject: RFR: 8174819: java/nio/file/WatchService/LotsOfEvents.java fails intermittently [v2] In-Reply-To: References: Message-ID: On Sun, 26 Sep 2021 12:31:33 GMT, Jaikiran Pai wrote: >> Can I please get a review for this test-only change that aims to fix an intermittent failure in `LotsOfEvents` testcase? >> >> As noted by Alan in the JBS issue https://bugs.openjdk.java.net/browse/JDK-8174819, the test failure is likely due to the relatively smaller poll timeout that it currently uses. IMO, this guess is proved right by the diagnostic logs that the test is currently printing, as I note in my comment in that JBS issue. >> >> The commit in this PR increases the 2 second timeout that was used (only) in the loop to 15 seconds to make it match the poll timeout that is used outside the loop. IMO, this increase in timeout shouldn't really slow down the test, since this is the "max amount of time to wait". The 13 second additional wait would ideally only show for the "last" poll where there are no more events. >> >> Additionally, this commit also adds a few more diagnostic logs for future use, if this test fails in future. >> >> Do note that there's also a `testModifyEventsQueuing` test method which too uses a 2 second timeout in a loop. I haven't touched/changed that timeout, since that test hasn't yet failed (perhaps because the number of events generated there are just 100 as against 1024 in this `testOverflowEvent` test). If at all that other test fails any time in future, we can perhaps consider increasing the timeout there too. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Thank you Alan for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5693 From jpai at openjdk.java.net Tue Sep 28 04:57:57 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 28 Sep 2021 04:57:57 GMT Subject: Integrated: 8174819: java/nio/file/WatchService/LotsOfEvents.java fails intermittently In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 07:02:12 GMT, Jaikiran Pai wrote: > Can I please get a review for this test-only change that aims to fix an intermittent failure in `LotsOfEvents` testcase? > > As noted by Alan in the JBS issue https://bugs.openjdk.java.net/browse/JDK-8174819, the test failure is likely due to the relatively smaller poll timeout that it currently uses. IMO, this guess is proved right by the diagnostic logs that the test is currently printing, as I note in my comment in that JBS issue. > > The commit in this PR increases the 2 second timeout that was used (only) in the loop to 15 seconds to make it match the poll timeout that is used outside the loop. IMO, this increase in timeout shouldn't really slow down the test, since this is the "max amount of time to wait". The 13 second additional wait would ideally only show for the "last" poll where there are no more events. > > Additionally, this commit also adds a few more diagnostic logs for future use, if this test fails in future. > > Do note that there's also a `testModifyEventsQueuing` test method which too uses a 2 second timeout in a loop. I haven't touched/changed that timeout, since that test hasn't yet failed (perhaps because the number of events generated there are just 100 as against 1024 in this `testOverflowEvent` test). If at all that other test fails any time in future, we can perhaps consider increasing the timeout there too. This pull request has now been integrated. Changeset: 633eab23 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/633eab23f0c5cadac06e37b9d6eeef5696ca3d22 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod 8174819: java/nio/file/WatchService/LotsOfEvents.java fails intermittently Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5693 From redestad at openjdk.java.net Tue Sep 28 10:05:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 28 Sep 2021 10:05:05 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v3] In-Reply-To: References: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> Message-ID: <8nRoQznW3BlIXu7y0t9HhBgX1vMgFQAb6yoROtWQ7kA=.caa9857b-5c1c-4c68-ad15-05aaf02afc93@github.com> On Mon, 27 Sep 2021 12:11:22 GMT, Claes Redestad wrote: >> src/hotspot/share/opto/c2compiler.cpp line 222: >> >>> 220: #if !defined(X86) >>> 221: return false; // not yet implemented >>> 222: #endif >> >> It might be a little more work, but I think it's cleaner to move the decision whether the intrinisc is supported into the Matcher like for most other intrinsics and keep this code here platform independent. Otherwise we will get an increasing cascade of ifdefs as people start implementing this for other platforms. > > Not too much work. I recently introduced platform-specific `matcher_*.hpp` files, so since then adding a boolean constant is easy (no need to muck with the .ad files). Does the changes in 9800a99 resolve your concerns? ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Tue Sep 28 10:11:36 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 28 Sep 2021 10:11:36 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v4] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Fix logic error ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/9800a99a..47633cba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Tue Sep 28 11:49:29 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 28 Sep 2021 11:49:29 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v5] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add fail-safe predicate to all encode_iso_array to only match non-ASCII EncodeISOArrayNodes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/47633cba..b4a5d105 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=03-04 Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From simonis at openjdk.java.net Tue Sep 28 11:53:22 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 28 Sep 2021 11:53:22 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v5] In-Reply-To: <8nRoQznW3BlIXu7y0t9HhBgX1vMgFQAb6yoROtWQ7kA=.caa9857b-5c1c-4c68-ad15-05aaf02afc93@github.com> References: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> <8nRoQznW3BlIXu7y0t9HhBgX1vMgFQAb6yoROtWQ7kA=.caa9857b-5c1c-4c68-ad15-05aaf02afc93@github.com> Message-ID: On Tue, 28 Sep 2021 10:01:43 GMT, Claes Redestad wrote: >> Not too much work. I recently introduced platform-specific `matcher_*.hpp` files, so since then adding a boolean constant is easy (no need to muck with the .ad files). > > Does the changes in 9800a99 resolve your concerns? In principle yes, but shouldn't the condition read: if (!Matcher::match_rule_supported(Op_EncodeISOArray) || !Matcher::supports_encode_ascii_array) return false; I.e. the intrinisc is supported if both conditions are true and not supported if either one of them is false? ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From claes.redestad at oracle.com Tue Sep 28 12:39:54 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 28 Sep 2021 12:39:54 +0000 Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v5] In-Reply-To: References: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> <8nRoQznW3BlIXu7y0t9HhBgX1vMgFQAb6yoROtWQ7kA=.caa9857b-5c1c-4c68-ad15-05aaf02afc93@github.com> Message-ID: Yes, this was spotted and fixed already. Annoyingly the test I added didn't detect this so GHA was green, but it failed some tier2 tests on aarch64. I added extra safeguards by predicating matching the encode_iso_array instructions on the node being !ascii, which will cause C2 to report an error rather than silently using the iso variant for ascii-only nodes. H?mta Outlook f?r Android ________________________________ From: core-libs-dev on behalf of Volker Simonis Sent: Tuesday, September 28, 2021 1:53:22 PM To: core-libs-dev at openjdk.java.net ; hotspot-compiler-dev at openjdk.java.net ; nio-dev at openjdk.java.net Subject: Re: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v5] On Tue, 28 Sep 2021 10:01:43 GMT, Claes Redestad wrote: >> Not too much work. I recently introduced platform-specific `matcher_*.hpp` files, so since then adding a boolean constant is easy (no need to muck with the .ad files). > > Does the changes in 9800a99 resolve your concerns? In principle yes, but shouldn't the condition read: if (!Matcher::match_rule_supported(Op_EncodeISOArray) || !Matcher::supports_encode_ascii_array) return false; I.e. the intrinisc is supported if both conditions are true and not supported if either one of them is false? ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thartmann at openjdk.java.net Tue Sep 28 15:14:42 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 28 Sep 2021 15:14:42 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v5] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 11:49:29 GMT, Claes Redestad wrote: >> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. >> >> Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add fail-safe predicate to all encode_iso_array to only match non-ASCII EncodeISOArrayNodes The latest version looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5621 From shade at openjdk.java.net Tue Sep 28 16:04:21 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 28 Sep 2021 16:04:21 GMT Subject: RFR: 8274453: (sctp) com/sun/nio/sctp/SctpChannel/CloseDescriptors.java test should be resilient to lsof warnings Message-ID: Recently added test fails on my desktop in the course of newly added `tier4` runs. The reason is simple: the test verifies that lsof outputs no more than LIMIT_LINES (2) lines. And on my machine, lsof prints some warnings that blow that limit. In the patch, lsof -w is used to suppress the warnings. Additional testing: - [x] Affected test now passes ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5739/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5739&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274453 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5739.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5739/head:pull/5739 PR: https://git.openjdk.java.net/jdk/pull/5739 From redestad at openjdk.java.net Wed Sep 29 12:36:23 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 29 Sep 2021 12:36:23 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v6] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Clean up and make TestEncodeIntrinsics fail on the particular scenario where the ISO intrinsic was used in place of the ASCII-only intrinsic ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/b4a5d105..4ad9c08a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=04-05 Stats: 8 lines in 1 file changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Wed Sep 29 12:41:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 29 Sep 2021 12:41:40 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v6] In-Reply-To: References: <5lVTU7su0xmkfNlex-Pv_yoeuJpnoCyalI42oLSjGzg=.54d143bc-ede4-4ec8-a257-1538f43ea632@github.com> Message-ID: On Mon, 27 Sep 2021 12:27:32 GMT, Tobias Hartmann wrote: >>> Should we remove the "iso" part from the method/class names? >> >> I'm open to suggestions, but I've not been able to think of anything better. `encodeISOOrASCII` doesn't seem helpful and since ASCII is a subset of the ISO-8859-1 encoding referred to by the "iso" moniker then the ASCII-only variant is technically encoding chars to valid ISO-8859-1. > >> > Should we remove the "iso" part from the method/class names? >> >> I'm open to suggestions, but I've not been able to think of anything better. `encodeISOOrASCII` doesn't seem helpful and since ASCII is a subset of the ISO-8859-1 encoding referred to by the "iso" moniker then the ASCII-only variant is technically encoding chars to valid ISO-8859-1. > > Okay, that's fine with me. Thanks for reviewing, @TobiHartmann I also cleaned up the test and made sure it fails when there's a logic bug like the one I introduced in 9800a99 where the ISO array intrinsic would be matched for a case requiring the ASCII-only array intrinsic. The test was (in)conveniently never testing out-of-range characters in the 0x80-0xFF range, which is precisely where the two intrinsics would produce different results. I hope this doesn't require another 24 hour grace period. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From thartmann at openjdk.java.net Wed Sep 29 12:45:34 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 29 Sep 2021 12:45:34 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v6] In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 12:36:23 GMT, Claes Redestad wrote: >> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. >> >> Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Clean up and make TestEncodeIntrinsics fail on the particular scenario where the ISO intrinsic was used in place of the ASCII-only intrinsic The incremental change looks good and trivial to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Wed Sep 29 12:53:24 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 29 Sep 2021 12:53:24 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v7] In-Reply-To: References: Message-ID: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Clean up some stale test comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5621/files - new: https://git.openjdk.java.net/jdk/pull/5621/files/4ad9c08a..ebe509ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5621&range=05-06 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5621/head:pull/5621 PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Wed Sep 29 12:58:33 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 29 Sep 2021 12:58:33 GMT Subject: RFR: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 [v7] In-Reply-To: References: <_Dzhdy1vRupNXlRezru6UpkvEJV3Vlr149pbkryW2I4=.4c6e5e5b-7026-4410-9848-2a8d12aa71f7@github.com> <8nRoQznW3BlIXu7y0t9HhBgX1vMgFQAb6yoROtWQ7kA=.caa9857b-5c1c-4c68-ad15-05aaf02afc93@github.com> Message-ID: On Tue, 28 Sep 2021 11:49:28 GMT, Volker Simonis wrote: >> Does the changes in 9800a99 resolve your concerns? > > In principle yes, but shouldn't the condition read: > > if (!Matcher::match_rule_supported(Op_EncodeISOArray) || !Matcher::supports_encode_ascii_array) return false; > > I.e. the intrinisc is supported if both conditions are true and not supported if either one of them is false? Resolved in 47633cb ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From redestad at openjdk.java.net Wed Sep 29 13:02:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 29 Sep 2021 13:02:05 GMT Subject: Integrated: 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote: > This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on par with (or outperform) similarly getting charset encoded bytes from a String. The former took a small performance hit in JDK 9, and the latter improved greatly in the same release. > > Extending the `EncodeIsoArray` intrinsics on other platforms should be possible, but I'm unfamiliar with the macro assembler in general and unlike the x86 intrinsic they don't use a simple vectorized mask to implement the latin-1 check. For example aarch64 seem to filter out the low bytes and then check if there's any bits set in the high bytes. Clever, but very different to the 0xFF80 2-byte mask that an ASCII test wants. This pull request has now been integrated. Changeset: aaa36cc0 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/aaa36cc0069043e34b47e89769eb9eba39e5362a Stats: 783 lines in 28 files changed: 392 ins; 355 del; 36 mod 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86 Reviewed-by: naoto, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/5621 From prappo at openjdk.java.net Wed Sep 29 13:41:47 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 29 Sep 2021 13:41:47 GMT Subject: RFR: 8274509: Remove stray * and stylistic . from doc comments Message-ID: Please review this trivial change. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/5749/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5749&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274509 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5749.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5749/head:pull/5749 PR: https://git.openjdk.java.net/jdk/pull/5749 From alanb at openjdk.java.net Wed Sep 29 13:41:47 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 29 Sep 2021 13:41:47 GMT Subject: RFR: 8274509: Remove stray * and stylistic . from doc comments In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 12:50:59 GMT, Pavel Rappo wrote: > Please review this trivial change. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5749 From dfuchs at openjdk.java.net Wed Sep 29 13:48:33 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 29 Sep 2021 13:48:33 GMT Subject: RFR: 8274509: Remove stray * and stylistic . from doc comments In-Reply-To: References: Message-ID: <8FQkYPBbrGAaE01rOLvjAXzY9HCf38FJ1pDsCRQgoDc=.62c7ac3a-b4f0-4707-a0d9-5c458ba87e6a@github.com> On Wed, 29 Sep 2021 12:50:59 GMT, Pavel Rappo wrote: > Please review this trivial change. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5749 From lancea at openjdk.java.net Wed Sep 29 16:11:32 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 29 Sep 2021 16:11:32 GMT Subject: RFR: 8274509: Remove stray * and stylistic . from doc comments In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 12:50:59 GMT, Pavel Rappo wrote: > Please review this trivial change. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5749 From iris at openjdk.java.net Wed Sep 29 16:16:30 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 29 Sep 2021 16:16:30 GMT Subject: RFR: 8274509: Remove stray * and stylistic . from doc comments In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 12:50:59 GMT, Pavel Rappo wrote: > Please review this trivial change. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5749 From bpb at openjdk.java.net Wed Sep 29 17:03:30 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 29 Sep 2021 17:03:30 GMT Subject: RFR: 8274509: Remove stray * and stylistic . from doc comments In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 12:50:59 GMT, Pavel Rappo wrote: > Please review this trivial change. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5749 From prappo at openjdk.java.net Wed Sep 29 17:12:32 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 29 Sep 2021 17:12:32 GMT Subject: Integrated: 8274509: Remove stray * and stylistic . from doc comments In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 12:50:59 GMT, Pavel Rappo wrote: > Please review this trivial change. This pull request has now been integrated. Changeset: 97b28742 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/97b28742b4d3083cadbe4dc10b625ec9fb944353 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8274509: Remove stray * and stylistic . from doc comments Reviewed-by: alanb, dfuchs, lancea, iris, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5749 From mik3hall at gmail.com Wed Sep 29 17:28:24 2021 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 29 Sep 2021 12:28:24 -0500 Subject: Circular loading of installed providers detected Message-ID: I have a FileSystemProvider with something like? public MacFileSystemProvider() { List providers = FileSystemProvider.installedProviders(); for (FileSystemProvider provider : providers) { To search for the platform ?file? scheme provider to set as it?s priorProvider. I was trying to launch code that apparently attemps to reinstantiate a new no args instance (JShell via API) getting? Caused by: java.lang.Error: Circular loading of installed providers detected at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(Unknown Source) at us.hall.trz.osx.MacFileSystemProvider.(MacFileSystemProvider.java:41) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ? This isn?t really circular it is just being done a second time. Should it be up to installedProviders() to know it has already been done and return what it already loaded? Or should my code handle this probably by changing it?s saved priorProvider to static and not trying to set it again if it is not null? From Alan.Bateman at oracle.com Wed Sep 29 19:02:00 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Sep 2021 20:02:00 +0100 Subject: Circular loading of installed providers detected In-Reply-To: References: Message-ID: On 29/09/2021 18:28, Michael Hall wrote: > I have a FileSystemProvider with something like? > > public MacFileSystemProvider() { > List providers = FileSystemProvider.installedProviders(); > for (FileSystemProvider provider : providers) { > > To search for the platform ?file? scheme provider to set as it?s priorProvider. > > I was trying to launch code that apparently attemps to reinstantiate a new no args instance (JShell via API) > getting? > > Caused by: java.lang.Error: Circular loading of installed providers detected > at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(Unknown Source) > at us.hall.trz.osx.MacFileSystemProvider.(MacFileSystemProvider.java:41) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > ? > > This isn?t really circular it is just being done a second time. > > Should it be up to installedProviders() to know it has already been done and return what it already loaded? > > Or should my code handle this probably by changing it?s saved priorProvider to static and not trying to set it again if it is not null? > If you change the public constructor to have a FileSystemProvider parameter then it will be called with a reference to the built-in provider. That should avoid the need to iterated through the installed providers. -Alan. From mik3hall at gmail.com Wed Sep 29 20:59:48 2021 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 29 Sep 2021 15:59:48 -0500 Subject: Circular loading of installed providers detected In-Reply-To: References: Message-ID: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> > On Sep 29, 2021, at 2:02 PM, Alan Bateman wrote: > > On 29/09/2021 18:28, Michael Hall wrote: >> I have a FileSystemProvider with something like? >> >> public MacFileSystemProvider() { >> List providers = FileSystemProvider.installedProviders(); >> for (FileSystemProvider provider : providers) { >> >> To search for the platform ?file? scheme provider to set as it?s priorProvider. >> >> I was trying to launch code that apparently attemps to reinstantiate a new no args instance (JShell via API) >> getting? >> >> Caused by: java.lang.Error: Circular loading of installed providers detected >> at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(Unknown Source) >> at us.hall.trz.osx.MacFileSystemProvider.(MacFileSystemProvider.java:41) >> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> ? >> >> This isn?t really circular it is just being done a second time. >> >> Should it be up to installedProviders() to know it has already been done and return what it already loaded? >> >> Or should my code handle this probably by changing it?s saved priorProvider to static and not trying to set it again if it is not null? >> > If you change the public constructor to have a FileSystemProvider parameter then it will be called with a reference to the built-in provider. That should avoid the need to iterated through the installed providers. > > -Alan. The class has both constructors. With and without. I don?t remember why. The JShell invocation does seem to use the no argument. Sorry for the length, full stack traces? System.out.println("Hello, World!") java.lang.InternalError: Exception during parse - java.util.ServiceConfigurationError: java.nio.file.spi.FileSystemProvider: Provider us.hall.trz.osx.MacFileSystemProvider could not be instantiated at jdk.jshell/jdk.jshell.TaskFactory$ParseTask.parse(Unknown Source) at jdk.jshell/jdk.jshell.TaskFactory$ParseTask.(Unknown Source) at jdk.jshell/jdk.jshell.TaskFactory.lambda$parse$0(Unknown Source) at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(Unknown Source) at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(Unknown Source) at jdk.jshell/jdk.jshell.TaskFactory.runTask(Unknown Source) at jdk.jshell/jdk.jshell.TaskFactory.parse(Unknown Source) at jdk.jshell/jdk.jshell.TaskFactory.parse(Unknown Source) at jdk.jshell/jdk.jshell.Eval.sourceToSnippets(Unknown Source) at jdk.jshell/jdk.jshell.Eval.eval(Unknown Source) at jdk.jshell/jdk.jshell.JShell.eval(Unknown Source) at us.hall.repl.JShellReplImpl.main(JShellReplImpl.java:27) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at org.cmdline.psuedoGestalt.Runner.invoke(Runner.java:209) at org.cmdline.psuedoGestalt.Runner.runStatic(Runner.java:236) at org.cmdline.psuedoGestalt.Runner.runMain(Runner.java:228) at org.cmdline.psuedoGestalt.Runner.run(Runner.java:146) Caused by: java.lang.RuntimeException: java.util.ServiceConfigurationError: java.nio.file.spi.FileSystemProvider: Provider us.hall.trz.osx.MacFileSystemProvider could not be instantiated at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(Unknown Source) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.parse(Unknown Source) ... 20 more Caused by: java.util.ServiceConfigurationError: java.nio.file.spi.FileSystemProvider: Provider us.hall.trz.osx.MacFileSystemProvider could not be instantiated at java.base/java.util.ServiceLoader.fail(Unknown Source) at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(Unknown Source) at java.base/java.util.ServiceLoader$ProviderImpl.get(Unknown Source) at java.base/java.util.ServiceLoader$3.next(Unknown Source) at java.base/java.nio.file.spi.FileSystemProvider.loadInstalledProviders(Unknown Source) at java.base/java.nio.file.spi.FileSystemProvider$1.run(Unknown Source) at java.base/java.nio.file.spi.FileSystemProvider$1.run(Unknown Source) at java.base/java.security.AccessController.doPrivileged(Unknown Source) at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.FSInfo.getJarFSProvider(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.Locations$SearchPath.addFile(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.Locations$SearchPath.addFiles(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.Locations$SearchPath.addFiles(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.Locations$SearchPath.addFiles(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.Locations$ClassPathLocationHandler.computePath(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.Locations$SimpleLocationHandler.setPaths(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.Locations$ClassPathLocationHandler.lazy(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.Locations$ClassPathLocationHandler.getPaths(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.Locations.getLocation(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.JavacFileManager.getLocation(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.JavacFileManager.getClassLoader(Unknown Source) at jdk.jshell/jdk.jshell.MemoryFileManager.getClassLoader(Unknown Source) at jdk.compiler/com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager.getClassLoader(Unknown Source) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.initProcessorLoader(Unknown Source) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.(Unknown Source) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.instance(Unknown Source) at jdk.compiler/com.sun.tools.javac.api.BasicJavacTask.initPlugins(Unknown Source) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.prepareCompiler(Unknown Source) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.parseInternal(Unknown Source) ... 22 more Caused by: java.lang.Error: Circular loading of installed providers detected at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(Unknown Source) at us.hall.trz.osx.MacFileSystemProvider.(MacFileSystemProvider.java:41) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Unknown Source) at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source) at java.base/java.util.ServiceLoader$ProviderImpl$2.run(Unknown Source) at java.base/java.security.AccessController.doPrivileged(Unknown Source) ... 50 more From mik3hall at gmail.com Wed Sep 29 22:18:15 2021 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 29 Sep 2021 17:18:15 -0500 Subject: Circular loading of installed providers detected In-Reply-To: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> References: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> Message-ID: <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> >>> >> If you change the public constructor to have a FileSystemProvider parameter then it will be called with a reference to the built-in provider. That should avoid the need to iterated through the installed providers. >> I eliminated the no args constructor and added a couple printStackTrace?s of my own in the constructors. I get this at startup java.lang.Exception: MacFileSystemProvider(fsp) at us.hall.trz.osx.MacFileSystemProvider.(MacFileSystemProvider.java:57) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Unknown Source) at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(Unknown Source) This invoking jshell from the app after getting rid of the no args constructor? Caused by: java.util.ServiceConfigurationError: java.nio.file.spi.FileSystemProvider: us.hall.trz.osx.MacFileSystemProvider Unable to get public no-arg constructor at java.base/java.util.ServiceLoader.fail(Unknown Source) at java.base/java.util.ServiceLoader.getConstructor(Unknown Source) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(Unknown Source) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Unknown Source) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Unknown Source) at java.base/java.security.AccessController.doPrivileged(Unknown Source) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Unknown Source) at java.base/java.util.ServiceLoader$2.hasNext(Unknown Source) at java.base/java.util.ServiceLoader$3.hasNext(Unknown Source) at java.base/java.nio.file.spi.FileSystemProvider.loadInstalledProviders(Unknown Source) at java.base/java.nio.file.spi.FileSystemProvider$1.run(Unknown Source) at java.base/java.nio.file.spi.FileSystemProvider$1.run(Unknown Source) at java.base/java.security.AccessController.doPrivileged(Unknown Source) at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(Unknown Source) at jdk.compiler/com.sun.tools.javac.file.FSInfo.getJarFSProvider(Unknown Source) So eliminating the no args is not a fix. Apparently mixing in a JarFSProvider has a conflict? I don?t think my code can handle this itself as it fails with or without the no args. From bpb at openjdk.java.net Wed Sep 29 22:32:09 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 29 Sep 2021 22:32:09 GMT Subject: RFR: 8268435: (ch) ChannelInputStream could override readAllBytes [v4] In-Reply-To: References: Message-ID: > This change would override `readAllBytes()` and `readNBytes(int)` in `ChannelInputStream` thereby improving performance for all but smaller streams. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8268435: Split up @Tests into multiple, smaller @Tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5645/files - new: https://git.openjdk.java.net/jdk/pull/5645/files/4ad8e2ab..2b131c08 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5645&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5645&range=02-03 Stats: 454 lines in 2 files changed: 311 ins; 143 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5645/head:pull/5645 PR: https://git.openjdk.java.net/jdk/pull/5645 From bpb at openjdk.java.net Wed Sep 29 22:38:31 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 29 Sep 2021 22:38:31 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v4] In-Reply-To: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> References: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> Message-ID: <0JFVLcWIwQhi1CTQb7jUN8jIpvl0jVjxBNekpyFPM64=.a55bf1c0-057f-4d85-adc9-882755e2cfff@github.com> On Sun, 26 Sep 2021 13:44:31 GMT, Markus KARG wrote: >> Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. >> >> This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. >> >> *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Comment for checkTransferredContents > > Signed-off-by: Markus Karg The comments are much improved but inconsistent. For example some of them have `@param` and other javadoc tags and some do not. There is also some variation in detail level. On a process level, it would be better to wait for feedback on changes before integrating. This is especially so as a sponsor has to be comfortable with the content. Ideally at least one approval should be associated with the most recent commit. test/jdk/java/nio/channels/Channels/TransferTo.java line 28: > 26: import static org.testng.Assert.assertEquals; > 27: import static org.testng.Assert.assertThrows; > 28: import static org.testng.Assert.assertTrue; Static imports in tests are usually grouped by convention after regular imports. ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From bpb at openjdk.java.net Wed Sep 29 22:48:31 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 29 Sep 2021 22:48:31 GMT Subject: RFR: 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test [v4] In-Reply-To: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> References: <-PMxcGHIF0ez0WZp1-QQHArOeKTGF5vrC9ZK53dU5OY=.c79817a8-29ed-4bb3-94e7-5a4d3cdd425a@github.com> Message-ID: On Sun, 26 Sep 2021 13:44:31 GMT, Markus KARG wrote: >> Using TestNG makes it easier to maintain and extend the unit test of ChannelInputStream::transferTo. >> >> This change was proposed by Brian Burkhalter @blbp and requested Alan Bateman @AlanBateman. >> >> *Note: A further test addition (testing 2GB+ transfers) will be added by me in a subsequent PR using TestNG once *this* PR is merged. This will need a while due to personal scheduling, also the topics are not necessarily related, hence there are separate PRs.* > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Comment for checkTransferredContents > > Signed-off-by: Markus Karg test/jdk/java/nio/channels/Channels/TransferTo.java line 105: > 103: checkTransferredContents(inputStreamProvider, outputStreamProvider, new byte[0]); > 104: > 105: // tests input stream with a lenght between 1k and 4k "lenght" should be "length" ------------- PR: https://git.openjdk.java.net/jdk/pull/5421 From mik3hall at gmail.com Wed Sep 29 23:56:05 2021 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 29 Sep 2021 18:56:05 -0500 Subject: Circular loading of installed providers detected In-Reply-To: <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> References: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> Message-ID: <35D744C2-0B2E-45ED-B382-2FE19471F807@gmail.com> > On Sep 29, 2021, at 5:18 PM, Michael Hall wrote: > >>>> >>> If you change the public constructor to have a FileSystemProvider parameter then it will be called with a reference to the built-in provider. That should avoid the need to iterated through the installed providers. >>> It occurred to me setting a static priorProvider at startup would still be a work around. So I put the no args back in but it just throws an exception if the priorProvider is null, otherwise does nothing else. Invoking jshell? System.out.println("Hello, World!") error: No file system provider is available to handle this file: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app/halfpipe.jar It gives that error for every jar in java.class.path, but then, Hello, World! A fairly ugly workaround at this point but a work around. Having a one time and one time only method like installedProviders() is sort of strange. From github.com+489445+ajbaldocchi at openjdk.java.net Thu Sep 30 04:12:41 2021 From: github.com+489445+ajbaldocchi at openjdk.java.net (Anthony Baldocchi) Date: Thu, 30 Sep 2021 04:12:41 GMT Subject: RFR: JDK-8262957 (fs) Fail fast in UnixFileStore.isExtendedAttributesEnabled In-Reply-To: References: Message-ID: <6T-Y9r4kaiAZaWGHjJ9bNopLJm2HZzLLVwezjLeLS90=.bfeb8d28-5d8d-4f96-bb31-c777be5e9195@github.com> On Wed, 3 Mar 2021 22:15:38 GMT, Sebastian Stenzel wrote: > Added new capability flag `UnixNativeDispatcher.SUPPORTS_XATTR`, which gets set `#ifdef _SYS_XATTR_H_`. > > Note that `_SYS_XATTR_H_` is defined in `xattr.h` in both [macOS/Darwin](https://github.com/apple/darwin-xnu/blob/main/bsd/sys/xattr.h), [Linux and GNU-based BSD systems using glibc](https://github.com/bminor/glibc/blob/master/misc/sys/xattr.h). It might not be defined for other operating systems that still support xattr. So if OpenJDK eventually adds support for further platforms, this might need to be adjusted as well. > > If xattr capabilities are missing, `UnixFileStore.isExtendedAttributesEnabled` will return false immediately, avoiding any I/O. > > As a side effect of this change, I redefined some other (private) capabilities. Strictly speaking, this change is not required but keeps the code consistent, as [previously discussed in the mailing list](https://mail.openjdk.java.net/pipermail/nio-dev/2021-February/008133.html). Doesn't glibc use `_SYS_XATTR_H` rather than `_SYS_XATTR_H_`? Wouldn't it be better to use something like `XATTR_CREATE` instead of `_SYS_XATTR_H_`? ------------- PR: https://git.openjdk.java.net/jdk/pull/2816 From Alan.Bateman at oracle.com Thu Sep 30 06:29:24 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Sep 2021 07:29:24 +0100 Subject: Circular loading of installed providers detected In-Reply-To: <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> References: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> Message-ID: On 29/09/2021 23:18, Michael Hall wrote: > I eliminated the no args constructor and added a couple printStackTrace?s of my own in the constructors. I get this at startup > > java.lang.Exception: MacFileSystemProvider(fsp) > at us.hall.trz.osx.MacFileSystemProvider.(MacFileSystemProvider.java:57) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) > at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) > at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Unknown Source) > at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(Unknown Source) > > This invoking jshell from the app after getting rid of the no args constructor? > > Caused by: java.util.ServiceConfigurationError: java.nio.file.spi.FileSystemProvider: us.hall.trz.osx.MacFileSystemProvider Unable to get public no-arg constructor > at java.base/java.util.ServiceLoader.fail(Unknown Source) > at java.base/java.util.ServiceLoader.getConstructor(Unknown Source) > at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(Unknown Source) > at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Unknown Source) > at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Unknown Source) > at java.base/java.security.AccessController.doPrivileged(Unknown Source) > at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Unknown Source) > at java.base/java.util.ServiceLoader$2.hasNext(Unknown Source) > at java.base/java.util.ServiceLoader$3.hasNext(Unknown Source) > at java.base/java.nio.file.spi.FileSystemProvider.loadInstalledProviders(Unknown Source) > at java.base/java.nio.file.spi.FileSystemProvider$1.run(Unknown Source) > at java.base/java.nio.file.spi.FileSystemProvider$1.run(Unknown Source) > at java.base/java.security.AccessController.doPrivileged(Unknown Source) > at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(Unknown Source) > at jdk.compiler/com.sun.tools.javac.file.FSInfo.getJarFSProvider(Unknown Source) > > So eliminating the no args is not a fix. Apparently mixing in a JarFSProvider has a conflict? > I don?t think my code can handle this itself as it fails with or without the no args. I should have been clearer. I meant that if you have a 1-arg constructor then you should be able to remove your code that iterates over the installed provider to find the built-in/default provider. Also just to say that the spec has always had a warning about recursive initialization: "During construction a provider may safely access files associated with the default provider but care needs to be taken to avoid circular loading of other installed providers. If circular loading of installed providers is detected then an unspecified error is thrown." -Alan. From mik3hall at gmail.com Thu Sep 30 09:00:25 2021 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 30 Sep 2021 04:00:25 -0500 Subject: Circular loading of installed providers detected In-Reply-To: References: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> Message-ID: >> >> So eliminating the no args is not a fix. Apparently mixing in a JarFSProvider has a conflict? >> I don?t think my code can handle this itself as it fails with or without the no args. > I should have been clearer. I meant that if you have a 1-arg constructor then you should be able to remove your code that iterates over the installed provider to find the built-in/default provider. I do have a 1-arg constructor that gets invoked at application start up and works fine. I had a no args for some reason I don?t remember that would iterate installed providers to find the default ?file? provider since thats the only way it could get this information since it is not passed. As far as I can tell now my own code currently never uses this constructor. However, I wanted to use JShell via api. Apparently in running that wants to make use of a ?jar? provider? at jdk.compiler/com.sun.tools.javac.file.FSInfo.getJarFSProvider(Unknown Source) In it?s own startup it uses installedProviders() at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(Unknown Source) That itself at some point tries to use ServiceLoader to load my provider (again - it was loaded at startup) with a no-arg constructor. From what I sent earlier if I don?t have one you get the following error. If I do have a no-arg to create a functional instance it almost has to use installedProviders() itself to determine the fallback platform provider. Unless I static save the platform provider I get at startup with the 1-arg constructor. Even then if my no-arg constructor does pretty much nothing it still gets errors on every jar file. But no circular error. Caused by: java.util.ServiceConfigurationError: java.nio.file.spi.FileSystemProvider: us.hall.trz.osx.MacFileSystemProvider Unable to get public no-arg constructor For some reason, probably because I am currently the default provider it tries to invoke my no-arg constructor. It fails if I don?t have one. It throws the circular error if I have one that also tries to do a installedProviders(). It works but throws errors on every jar file in classpath if I have a no-args that doesn?t do installedProviders() I can try to recreate this with the jdk test default provider for a bug report but something doesn?t seem to be working right here? > > Also just to say that the spec has always had a warning about recursive initialization: > > "During construction a provider may safely access files associated with the default provider but care needs to be taken to avoid circular loading of other installed providers. If circular loading of installed providers is detected then an unspecified error is thrown." > > -Alan. I was thinking again for some reason that it wasn?t recursive. It does seem to be. But it is not me that isn?t being careful, jshell apparently uses javac which in turn tries to use a jar provider that attempts to use ServiceLoader to _reload_ my provider. It does this for some reason with a no-arg constructor. It isn?t me starting the recursion. I don?t know how I can avoid it trying to call me? Maybe a provider can set something to indicate it has already been loaded and avoid anything trying to reload it again later? Again, I might be able to recreate this with the jdk test provider if you want? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Thu Sep 30 09:25:48 2021 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 30 Sep 2021 04:25:48 -0500 Subject: Circular loading of installed providers detected In-Reply-To: References: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> Message-ID: > On Sep 30, 2021, at 4:00 AM, Michael Hall wrote: > > > >>> >>> So eliminating the no args is not a fix. Apparently mixing in a JarFSProvider has a conflict? >>> I don?t think my code can handle this itself as it fails with or without the no args. >> I should have been clearer. I meant that if you have a 1-arg constructor then you should be able to remove your code that iterates over the installed provider to find the built-in/default provider. > > I do have a 1-arg constructor that gets invoked at application start up and works fine. I had a no args for some reason I don?t remember that would iterate installed providers to find the default ?file? provider since thats the only way it could get this information since it is not passed. As far as I can tell now my own code currently never uses this constructor. > > However, I wanted to use JShell via api. Apparently in running that wants to make use of a ?jar? provider? > > at jdk.compiler/com.sun.tools.javac.file.FSInfo.getJarFSProvider(Unknown Source) > > In it?s own startup it uses installedProviders() > > at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(Unknown Source) > > That itself at some point tries to use ServiceLoader to load my provider (again - it was loaded at startup) with a no-arg constructor. From what I sent earlier if I don?t have one you get the following error. If I do have a no-arg to create a functional instance it almost has to use installedProviders() itself to determine the fallback platform provider. Unless I static save the platform provider I get at startup with the 1-arg constructor. Even then if my no-arg constructor does pretty much nothing it still gets errors on every jar file. But no circular error. > > Caused by: java.util.ServiceConfigurationError: java.nio.file.spi.FileSystemProvider: us.hall.trz.osx.MacFileSystemProvider Unable to get public no-arg constructor > > For some reason, probably because I am currently the default provider it tries to invoke my no-arg constructor. It fails if I don?t have one. It throws the circular error if I have one that also tries to do a installedProviders(). It works but throws errors on every jar file in classpath if I have a no-args that doesn?t do installedProviders() > > I can try to recreate this with the jdk test default provider for a bug report but something doesn?t seem to be working right here? > >> >> Also just to say that the spec has always had a warning about recursive initialization: >> >> "During construction a provider may safely access files associated with the default provider but care needs to be taken to avoid circular loading of other installed providers. If circular loading of installed providers is detected then an unspecified error is thrown." >> >> -Alan. > > I was thinking again for some reason that it wasn?t recursive. It does seem to be. But it is not me that isn?t being careful, jshell apparently uses javac which in turn tries to use a jar provider that attempts to use ServiceLoader to _reload_ my provider. It does this for some reason with a no-arg constructor. > It isn?t me starting the recursion. > > I don?t know how I can avoid it trying to call me? > > Maybe a provider can set something to indicate it has already been loaded and avoid anything trying to reload it again later? > > Again, I might be able to recreate this with the jdk test provider if you want? > Possibly the code could at some point check the java.nio.file.spi.DefaultFileSystemProvider property to be sure it wasn?t trying to reload the current default anyhow. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Thu Sep 30 18:02:07 2021 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 30 Sep 2021 13:02:07 -0500 Subject: Circular loading of installed providers detected In-Reply-To: References: <4E758452-9FB0-482A-B907-7E83DA673AA3@gmail.com> <1AAA176B-1B4A-42C5-884D-20C9F76D0A48@gmail.com> Message-ID: <0C7F8DDC-4EF8-450E-BBB9-BAD73F3DF984@gmail.com> > On Sep 30, 2021, at 4:25 AM, Michael Hall wrote: >> > > Possibly the code could at some point check the java.nio.file.spi.DefaultFileSystemProvider property to be sure it wasn?t trying to reload the current default anyhow. It still seems a bit of a awkward workaround but for a DefaultFileSystemProvider that saves its priorProvider static and includes a no-args that does nothing it works. I?m not sure if this would be necessary for any code that uses multiple providers. Or just code that replaces the default and then tries for another provider. For this error: No file system provider is available to handle this file: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app/halfpipe.j I found this indicating I needed an additional module? https://www.mail-archive.com/jigsaw-dev at openjdk.java.net/msg07033.html A comment might be that neither suggested error message tells you anything about needing a module. Adding that module exposed a bug in my provider getFileAttributeView method that when fixed got me? System.out.println("Hello, World!") Hello, World! So not that ugly a workaround anymore. A comment there still might be that loading recursion could be avoided. Having static boolean loaded = false; MyProvider() { loaded = true; } public static boolean isLoaded() { return loaded; } If my workaround needs a static priorProvider it seems like this wouldn?t be any worse and could eliminate recursion? Also definitely checking the DefaultFileSystemProvider so you don?t try to reload that seems like it makes sense? Thanks for the replies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.java.net Thu Sep 30 21:10:58 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 30 Sep 2021 21:10:58 GMT Subject: RFR: 8274562: (fs) UserDefinedFileAttributeView doesn't correctly determine if supported when using OverlayFS Message-ID: Add extended attributes to capabilities flag if `_SYS_XATTR_H` is defined. ------------- Commit messages: - 8274562: (fs) UserDefinedFileAttributeView doesn't correctly determine if supported when using OverlayFS Changes: https://git.openjdk.java.net/jdk/pull/5782/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5782&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274562 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5782.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5782/head:pull/5782 PR: https://git.openjdk.java.net/jdk/pull/5782