From david.holmes at oracle.com Wed Mar 1 02:05:54 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Mar 2017 12:05:54 +1000 Subject: 10 RFR: 8150687: typedefs without type names In-Reply-To: <33F5BF24-5892-4E14-962D-09CEF2F92FDB@oracle.com> References: <33F5BF24-5892-4E14-962D-09CEF2F92FDB@oracle.com> Message-ID: <2e8caf41-32a2-c060-4a69-53cb89ab2fe8@oracle.com> Hi Kim, nio-dev should look at this - cc'd. But looks fine to me. :) David On 1/03/2017 11:56 AM, Kim Barrett wrote: > Please review this small change, removing unnecessary uses of "typedef" that lead to warnings from Visual Studio 2015. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8150687 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8150687/jdk.00/ > > Testing: > jprt > From brian.burkhalter at oracle.com Wed Mar 1 02:20:33 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 28 Feb 2017 18:20:33 -0800 Subject: 10 RFR: 8150687: typedefs without type names In-Reply-To: <2e8caf41-32a2-c060-4a69-53cb89ab2fe8@oracle.com> References: <33F5BF24-5892-4E14-962D-09CEF2F92FDB@oracle.com> <2e8caf41-32a2-c060-4a69-53cb89ab2fe8@oracle.com> Message-ID: <207B8FE0-0F63-40E2-AA8D-98266EFC45D4@oracle.com> +1 Brian On Feb 28, 2017, at 6:05 PM, David Holmes wrote: > Hi Kim, > > nio-dev should look at this - cc'd. > > But looks fine to me. :) > > David > > On 1/03/2017 11:56 AM, Kim Barrett wrote: >> Please review this small change, removing unnecessary uses of "typedef" that lead to warnings from Visual Studio 2015. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8150687 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8150687/jdk.00/ >> >> Testing: >> jprt >> From daniel.fuchs at oracle.com Wed Mar 1 08:01:22 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 1 Mar 2017 08:01:22 +0000 Subject: RFC on java/nio/channels/FileChannel/InterruptDeadlock.java In-Reply-To: <0C3BD6AD-449D-4639-AE69-95A695F2EEF1@oracle.com> References: <0C3BD6AD-449D-4639-AE69-95A695F2EEF1@oracle.com> Message-ID: <85a0c91e-8f81-ce61-60f6-04ffc9b1197a@oracle.com> Hi Brian, Your proposed change looks reasonable to me. I doubt that it is related to [1] though. Or if it is, then it might be better not do the change ;-( As a measure of safety did you verify the test worked as expected after making the change? best regards, -- daniel On 28/02/17 22:43, Brian Burkhalter wrote: > I don?t know whether [1] could be related to this, but it looks to me as if the test InterruptDeadlock.java is incorrect at line 61 [2]. It appears that the value of pos will reach fc.size() which is 1024*1024 + 1 and remain there for all subsequent iterations of the loop in which case fc.read() at line 57 would no longer read any bytes. It seems that the greater-than (>) at line 61 should instead be greater-than-or-equal (>=). This would be consistent with the specification of FileChannel.read(ByteBuffer,long) [3] which states that it will return -1 if the position is greater than or equal to the file?s current size. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8151862 > [2] http://hg.openjdk.java.net/jdk9/dev/jdk/file/49b54a4d9e84/test/java/nio/channels/FileChannel/InterruptDeadlock.java#l51 > [3] http://download.java.net/java/jdk9/docs/api/java/nio/channels/FileChannel.html#read-java.nio.ByteBuffer-long- > From pavel.rappo at oracle.com Wed Mar 1 10:31:57 2017 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 1 Mar 2017 10:31:57 +0000 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> Message-ID: <3D30A645-741B-47FA-B59D-81034B7F0D8B@oracle.com> Looks good to me (I'm not a Reviewer though). > On 28 Feb 2017, at 21:15, Brian Burkhalter wrote: > > Improved version which counts the number of invocations of CompletionHandler.completed() instead of tracking the time of the most recent invocation: > > http://cr.openjdk.java.net/~bpb/8175209/webrev.01/ > > Also delete unused variable t0. > > Thanks, > > Brian > > On Feb 28, 2017, at 8:25 AM, Brian Burkhalter wrote: > >> Please review this test bug fix at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8175209 >> Patch: http://cr.openjdk.java.net/~bpb/8175209/webrev.00/ > From brian.burkhalter at oracle.com Wed Mar 1 16:04:08 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 1 Mar 2017 08:04:08 -0800 Subject: RFC on java/nio/channels/FileChannel/InterruptDeadlock.java In-Reply-To: <85a0c91e-8f81-ce61-60f6-04ffc9b1197a@oracle.com> References: <0C3BD6AD-449D-4639-AE69-95A695F2EEF1@oracle.com> <85a0c91e-8f81-ce61-60f6-04ffc9b1197a@oracle.com> Message-ID: <0CED1384-482E-4458-9EC3-108ABF443849@oracle.com> Hi Daniel, On Mar 1, 2017, at 12:01 AM, Daniel Fuchs wrote: > Your proposed change looks reasonable to me. Thanks. > I doubt that it is related to [1] though. I?ve been going through the implementation code and have not determined yet whether it could have an effect. > Or if it is, then it might be better not do the change ;-( Good point. > As a measure of safety did you verify the test worked as expected > after making the change? Yes. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Fri Mar 3 05:45:56 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 3 Mar 2017 13:45:56 +0800 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> Message-ID: Hi Brian, I believe the patch will improve the stability of the test than original version. But I'm afraid the patch will still face the intermittent failure, because there is still a time window for ch.write(genBuffer()); to run successfully, then exception is thrown at line 357. 356 ch.write(genBuffer()); 357 throw new RuntimeException("WritePendingException expected"); It can be reproduced by putting below code in a loop as below, and reduce the sleep time to 10, my local test result is to fail at about one hundred or hundreds of loops. for (int i = 0; i < 1000; i++) { // put below code in a loop 323 ch = AsynchronousSocketChannel.open(); 324 ch.connect(server.address()).get(); ...... 345 int prevNumCompleted = numCompleted.get(); 346 do { 347 Thread.sleep(*10*); 348 if (numCompleted.get() == prevNumCompleted) { 349 break; 350 } 351 prevNumCompleted = numCompleted.get(); 352 } while (true); 353 ...... 369 if (!(writeException.get() instanceof AsynchronousCloseException)) 370 throw new RuntimeException("AsynchronousCloseException expected", 371 writeException.get()); } // end of for loop The reason why it fails is because there are 2 writes, write_1) one is at line 331 and line 334, they continuously write to buffer, the writes are expected to run successfully except of the time when ch is closed. write_2) another is at line 356, it writes just once, and expected to fail with WritePendingException write_1 and write_2 are racy, any time wait or sync would not change the racy relationship, so the intermittent failure is expected ( based on original code or your patch). write_1) 331 ch.write(genBuffer(), ch, new CompletionHandler() { 332 public void completed(Integer result, AsynchronousSocketChannel ch) { 333 numCompleted.incrementAndGet(); 334 ch.write(genBuffer(), ch, this); 335 } write_2) 355 try { 356 ch.write(genBuffer()); 357 throw new RuntimeException("WritePendingException expected"); 358 } catch (WritePendingException x) { I think we can use the racy relationship between write_1 and write_2 rather than try to avoid it, How do you think about below solution? make write_2 to write continuously to the channel too. As write_1 and write_2 are racy, WritePendingException is expected to happen either in write_1 or write_2. If either write_1 or write_2 throw WritePendingException, the test is passed; if no exception is thrown(in a reasonable time span or in infinite time?), then the test fails. Thank you -Hamlin On 2017/3/1 5:15, Brian Burkhalter wrote: > Improved version which counts the number of invocations of > CompletionHandler.completed() instead of tracking the time of the most > recent invocation: > > http://cr.openjdk.java.net/~bpb/8175209/webrev.01/ > > > Also delete unused variable t0. > > Thanks, > > Brian > > On Feb 28, 2017, at 8:25 AM, Brian Burkhalter > > wrote: > >> Please review this test bug fix at your convenience. >> >> Issue:https://bugs.openjdk.java.net/browse/JDK-8175209 >> Patch:http://cr.openjdk.java.net/~bpb/8175209/webrev.00/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Mar 3 19:25:35 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 3 Mar 2017 11:25:35 -0800 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> Message-ID: <406311CC-B2DC-417D-B3C8-F6B9093E19E2@oracle.com> Hi Hamlin, Please see comments inline below. On Mar 2, 2017, at 9:45 PM, Hamlin Li wrote: > I believe the patch will improve the stability of the test than original version. > > But I'm afraid the patch will still face the intermittent failure, because there is still a time window for ch.write(genBuffer()); to run successfully, then exception is thrown at line 357. > > 356 ch.write(genBuffer()); > 357 throw new RuntimeException("WritePendingException expected"); > > > It can be reproduced by putting below code in a loop as below, and reduce the sleep time to 10, my local test result is to fail at about one hundred or hundreds of loops. > for (int i = 0; i < 1000; i++) { // put below code in a loop > > 323 ch = AsynchronousSocketChannel.open(); > 324 ch.connect(server.address()).get(); > ...... > 345 int prevNumCompleted = numCompleted.get(); > 346 do { > 347 Thread.sleep(10); > 348 if (numCompleted.get() == prevNumCompleted) { > 349 break; > 350 } > 351 prevNumCompleted = numCompleted.get(); > 352 } while (true); > 353 > ...... > 369 if (!(writeException.get() instanceof AsynchronousCloseException)) > 370 throw new RuntimeException("AsynchronousCloseException expected", > 371 writeException.get()); > } // end of for loop > > The reason why it fails is because there are 2 writes, > write_1) one is at line 331 and line 334, they continuously write to buffer, the writes are expected to run successfully except of the time when ch is closed. > write_2) another is at line 356, it writes just once, and expected to fail with WritePendingException > write_1 and write_2 are racy, any time wait or sync would not change the racy relationship, so the intermittent failure is expected ( based on original code or your patch). > > write_1) > 331 ch.write(genBuffer(), ch, new CompletionHandler() { > 332 public void completed(Integer result, AsynchronousSocketChannel ch) { > 333 numCompleted.incrementAndGet(); > 334 ch.write(genBuffer(), ch, this); > 335 } > > write_2) > 355 try { > 356 ch.write(genBuffer()); > 357 throw new RuntimeException("WritePendingException expected"); > 358 } catch (WritePendingException x) { I agree that there is still a race condition but I think it is much more likely to result in the expected exception than before, however it is still possible. In the loop you present above the sleep time is only 10 ms as opposed to the 1 second that I suggest in the patch so of course it is 100 times more probable that completed() will not have been invoked between pauses. > I think we can use the racy relationship between write_1 and write_2 rather than try to avoid it, > How do you think about below solution? > make write_2 to write continuously to the channel too. As write_1 and write_2 are racy, WritePendingException is expected to happen either in write_1 or write_2. If either write_1 or write_2 throw WritePendingException, the test is passed; if no exception is thrown(in a reasonable time span or in infinite time?), then the test fails. I actually thought of that as well. I think however that it is still possible that no WritePendingException is thrown if all the writes happen to ?miss? each other. I don?t know that there is a way to make the exception 100% guaranteed. Your suggestion however might make it even more likely that the expected exception will be seen so I will investigate changing my patch. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Mar 3 21:57:56 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 3 Mar 2017 13:57:56 -0800 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: <406311CC-B2DC-417D-B3C8-F6B9093E19E2@oracle.com> References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> <406311CC-B2DC-417D-B3C8-F6B9093E19E2@oracle.com> Message-ID: Here is a patch changed per my interpretation of Hamlin?s suggestion: http://cr.openjdk.java.net/~bpb/8175209/webrev.02/ Also ?new Random()" was replaced with RandomFactory.getRandom(). Thanks, Brian On Mar 3, 2017, at 11:25 AM, Brian Burkhalter wrote: > Your suggestion however might make it even more likely that the expected exception will be seen so I will investigate changing my patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Mon Mar 6 03:39:48 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 6 Mar 2017 11:39:48 +0800 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> <406311CC-B2DC-417D-B3C8-F6B9093E19E2@oracle.com> Message-ID: Hi Brian, It looks better to me, and it will be even better if you could scale the 1000 times loop with a timeout factor, that means loop more times when timeout factor is greater. BTW, I'm not a official reviewer. Thank you -Hamlin On 2017/3/4 5:57, Brian Burkhalter wrote: > Here is a patch changed per my interpretation of Hamlin?s suggestion: > > http://cr.openjdk.java.net/~bpb/8175209/webrev.02/ > > > Also ?new Random()" was replaced with RandomFactory.getRandom(). > > Thanks, > > Brian > > On Mar 3, 2017, at 11:25 AM, Brian Burkhalter > wrote: > >> Your suggestion however might make it even more likely that the >> expected exception will be seen so I will investigate changing my patch. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Mar 6 16:11:41 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Mar 2017 16:11:41 +0000 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> <406311CC-B2DC-417D-B3C8-F6B9093E19E2@oracle.com> Message-ID: <6e78cd13-3047-bdf5-8877-f8bd0d5b26b8@oracle.com> On 03/03/2017 21:57, Brian Burkhalter wrote: > Here is a patch changed per my interpretation of Hamlin?s suggestion: > > http://cr.openjdk.java.net/~bpb/8175209/webrev.02/ > > > Also ?new Random()" was replaced with RandomFactory.getRandom(). > The "give time for the socket buffer to fill up" changes look okay but the "// attempt concurrent writes" from L357 looks a bit ugly and should not be necessary. Can we leave the latter out of the changes and only come back to it if there are further stability issues? -Alan From brian.burkhalter at oracle.com Mon Mar 6 16:20:17 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 Mar 2017 08:20:17 -0800 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: <6e78cd13-3047-bdf5-8877-f8bd0d5b26b8@oracle.com> References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> <406311CC-B2DC-417D-B3C8-F6B9093E19E2@oracle.com> <6e78cd13-3047-bdf5-8877-f8bd0d5b26b8@oracle.com> Message-ID: On Mar 6, 2017, at 8:11 AM, Alan Bateman wrote: > The "give time for the socket buffer to fill up" changes look okay but the "// attempt concurrent writes" from L357 looks a bit ugly and should not be necessary. Can we leave the latter out of the changes and only come back to it if there are further stability issues? I concur. So you?re OK with http://cr.openjdk.java.net/~bpb/8175209/webrev.01/ ? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Mar 6 20:42:08 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Mar 2017 20:42:08 +0000 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> <406311CC-B2DC-417D-B3C8-F6B9093E19E2@oracle.com> <6e78cd13-3047-bdf5-8877-f8bd0d5b26b8@oracle.com> Message-ID: On 06/03/2017 16:20, Brian Burkhalter wrote: > On Mar 6, 2017, at 8:11 AM, Alan Bateman > wrote: > >> The "give time for the socket buffer to fill up" changes look okay >> but the "// attempt concurrent writes" from L357 looks a bit ugly >> and should not be necessary. Can we leave the latter out of the >> changes and only come back to it if there are further stability issues? > > I concur. So you?re OK with > > http://cr.openjdk.java.net/~bpb/8175209/webrev.01/ > > > ? > Looks fine. The use of the random library in the previous version was okay too although I'm pretty sure the issue is the sleep and your changes should significantly reduce the possibility of this. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Mar 6 20:54:45 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 Mar 2017 12:54:45 -0800 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> <406311CC-B2DC-417D-B3C8-F6B9093E19E2@oracle.com> <6e78cd13-3047-bdf5-8877-f8bd0d5b26b8@oracle.com> Message-ID: <250DDE20-BF0A-4729-940E-B7FE0DFA204E@oracle.com> On Mar 6, 2017, at 12:42 PM, Alan Bateman wrote: >> I concur. So you?re OK with >> >> http://cr.openjdk.java.net/~bpb/8175209/webrev.01/ >> >> ? >> > Looks fine. The use of the random library in the previous version was okay too although I'm pretty sure the issue is the sleep and your changes should significantly reduce the possibility of this. OK I think I?ll leave this as-is for now. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Mar 6 21:11:37 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 Mar 2017 13:11:37 -0800 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: <250DDE20-BF0A-4729-940E-B7FE0DFA204E@oracle.com> References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> <406311CC-B2DC-417D-B3C8-F6B9093E19E2@oracle.com> <6e78cd13-3047-bdf5-8877-f8bd0d5b26b8@oracle.com> <250DDE20-BF0A-4729-940E-B7FE0DFA204E@oracle.com> Message-ID: On Mar 6, 2017, at 12:54 PM, Brian Burkhalter wrote: >> Looks fine. The use of the random library in the previous version was okay too although I'm pretty sure the issue is the sleep and your changes should significantly reduce the possibility of this. > > OK I think I?ll leave this as-is for now. Actually I somehow have a mix up with my patches so I?ll keep the random factory in there but remove the multiple concurrent writes: http://cr.openjdk.java.net/~bpb/8175209/webrev.03/ Shall assume this is OK unless I hear otherwise. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Mar 7 00:28:31 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 Mar 2017 16:28:31 -0800 Subject: JDK 9 RFR of 8176237: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores Message-ID: <01DDC5DD-AC32-4325-81F5-F31AA60581B7@oracle.com> Please review a patch for this test issue: Issue: https://bugs.openjdk.java.net/browse/JDK-8176237 Patch: http://javaweb.us.oracle.com/~bburkhal/jdk9/review/8176237/webrev.00/ Similar to the change previously submitted in the patch for [1], attempt to access the FileStore enumeration only if ?df? does not hang (Unix-only). Also move the ?df? file system accessibility test code to jdk.testlibrary.FileUtils#areFileSystemsAccessible. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8173910 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Mar 7 18:51:25 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 7 Mar 2017 10:51:25 -0800 Subject: JDK 9 RFR of 8176317: (ch) Add print of timeout value to java/nio/channels/AsynchronousSocketChannel/Basic.java Message-ID: <13BCB14B-EBC1-4283-BBB8-4F2E385B5032@oracle.com> Please review this trivial fix for [1]: --- a/test/java/nio/channels/AsynchronousSocketChannel/Basic.java +++ b/test/java/nio/channels/AsynchronousSocketChannel/Basic.java @@ -775,6 +775,7 @@ } static void testTimeout(final long timeout, final TimeUnit unit) throws Exception { + System.out.printf("---- timeout: %d ms%n", unit.toMillis(timeout)); try (Server server = new Server()) { This change could be helpful in determining the cause of [2] should it occur again. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8176317 [2] https://bugs.openjdk.java.net/browse/JDK-8078590 From brian.burkhalter at oracle.com Wed Mar 8 00:49:48 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 7 Mar 2017 16:49:48 -0800 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() Message-ID: Please review this test-only change for [1]: --- a/test/java/nio/channels/Selector/ChangingInterests.java +++ b/test/java/nio/channels/Selector/ChangingInterests.java @@ -53,11 +53,11 @@ static void write1(SocketChannel peer) throws IOException { peer.write(ByteBuffer.wrap(new byte[1])); // give time for other end to be readable try { - Thread.sleep(50); + Thread.sleep(150); } catch (InterruptedException ignore) { } } The failure in [2] is due to the SocketChannel not having become readable. In theory this could have been due to an insufficient pause on a heavily loaded system. To reduce the odds of this happening, this patch increases the pause time from 50 to 150 ms, an execution time increase for the test of 400 ms total as the method write1() is invoked four times. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8176332 [2] https://bugs.openjdk.java.net/browse/JDK-8151749 From Alan.Bateman at oracle.com Wed Mar 8 16:10:34 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Mar 2017 16:10:34 +0000 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: Message-ID: On 08/03/2017 00:49, Brian Burkhalter wrote: > Please review this test-only change for [1]: > > --- a/test/java/nio/channels/Selector/ChangingInterests.java > +++ b/test/java/nio/channels/Selector/ChangingInterests.java > @@ -53,11 +53,11 @@ > > static void write1(SocketChannel peer) throws IOException { > peer.write(ByteBuffer.wrap(new byte[1])); > // give time for other end to be readable > try { > - Thread.sleep(50); > + Thread.sleep(150); > } catch (InterruptedException ignore) { } > } > > The failure in [2] is due to the SocketChannel not having become readable. In theory this could have been due to an insufficient pause on a heavily loaded system. To reduce the odds of this happening, this patch increases the pause time from 50 to 150 ms, an execution time increase for the test of 400 ms total as the method write1() is invoked four times. > This looks okay (longer is okay too) although it would be nice if there were a way to avoid the sleep. -Alan From Alan.Bateman at oracle.com Wed Mar 8 16:10:46 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Mar 2017 16:10:46 +0000 Subject: JDK 9 RFR of 8176317: (ch) Add print of timeout value to java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: <13BCB14B-EBC1-4283-BBB8-4F2E385B5032@oracle.com> References: <13BCB14B-EBC1-4283-BBB8-4F2E385B5032@oracle.com> Message-ID: <45b4dc1f-5e59-4a6d-30eb-d1ac94e6e167@oracle.com> On 07/03/2017 18:51, Brian Burkhalter wrote: > Please review this trivial fix for [1]: > > --- a/test/java/nio/channels/AsynchronousSocketChannel/Basic.java > +++ b/test/java/nio/channels/AsynchronousSocketChannel/Basic.java > @@ -775,6 +775,7 @@ > } > > static void testTimeout(final long timeout, final TimeUnit unit) throws Exception { > + System.out.printf("---- timeout: %d ms%n", unit.toMillis(timeout)); > try (Server server = new Server()) { > > This change could be helpful in determining the cause of [2] should it occur again. > Looks okay. From brian.burkhalter at oracle.com Wed Mar 8 19:12:13 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 8 Mar 2017 11:12:13 -0800 Subject: JDK 9 RFR of 8176394: Incorrect relational operator in java/nio/channels/FileChannel/InterruptDeadlock.java Message-ID: <270F23C4-BD2A-4836-A60E-55C8611BDDE5@oracle.com> Please review the change below for [1]. The Reader thread run() method is supposed to read continuously from the FileChannel fc. However ?pos? will eventually equal fc.size() at which point fc.read() will always return -1 and ?pos? will not be reset to zero in contravention of the intent of the test. Thanks, Brian @@ -51,21 +51,21 @@ public void run() { ByteBuffer bb = ByteBuffer.allocate(1024); try { long pos = 0L; for (;;) { bb.clear(); int n = fc.read(bb, pos); if (n > 0) pos += n; // fc.size is important here as it is position sensitive - if (pos > fc.size()) + if (pos >= fc.size()) pos = 0L; } } catch (ClosedChannelException x) { System.out.println(x.getClass() + " (expected)"); } catch (Exception unexpected) { this.exception = unexpected; } } [1] https://bugs.openjdk.java.net/browse/JDK-8176394 From Alan.Bateman at oracle.com Wed Mar 8 19:13:39 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Mar 2017 19:13:39 +0000 Subject: JDK 9 RFR of 8176394: Incorrect relational operator in java/nio/channels/FileChannel/InterruptDeadlock.java In-Reply-To: <270F23C4-BD2A-4836-A60E-55C8611BDDE5@oracle.com> References: <270F23C4-BD2A-4836-A60E-55C8611BDDE5@oracle.com> Message-ID: <7bd8555e-aa92-ca1c-ce62-4ff8ad72c2f6@oracle.com> Looks right. On 08/03/2017 19:12, Brian Burkhalter wrote: > Please review the change below for [1]. The Reader thread run() method is supposed to read continuously from the FileChannel fc. However ?pos? will eventually equal fc.size() at which point fc.read() will always return -1 and ?pos? will not be reset to zero in contravention of the intent of the test. > > Thanks, > > Brian > > @@ -51,21 +51,21 @@ > public void run() { > ByteBuffer bb = ByteBuffer.allocate(1024); > try { > long pos = 0L; > for (;;) { > bb.clear(); > int n = fc.read(bb, pos); > if (n > 0) > pos += n; > // fc.size is important here as it is position sensitive > - if (pos > fc.size()) > + if (pos >= fc.size()) > pos = 0L; > } > } catch (ClosedChannelException x) { > System.out.println(x.getClass() + " (expected)"); > } catch (Exception unexpected) { > this.exception = unexpected; > } > } > > [1] https://bugs.openjdk.java.net/browse/JDK-8176394 From Alan.Bateman at oracle.com Wed Mar 8 19:14:10 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Mar 2017 19:14:10 +0000 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> <406311CC-B2DC-417D-B3C8-F6B9093E19E2@oracle.com> <6e78cd13-3047-bdf5-8877-f8bd0d5b26b8@oracle.com> <250DDE20-BF0A-4729-940E-B7FE0DFA204E@oracle.com> Message-ID: <2c4c208b-aceb-b945-af20-674f203b6f39@oracle.com> On 06/03/2017 21:11, Brian Burkhalter wrote: > On Mar 6, 2017, at 12:54 PM, Brian Burkhalter > > wrote: > >>> Looks fine. The use of the random library in the previous version >>> was okay too although I'm pretty sure the issue is the sleep and >>> your changes should significantly reduce the possibility of this. >> >> OK I think I?ll leave this as-is for now. > > Actually I somehow have a mix up with my patches so I?ll keep the > random factory in there but remove the multiple concurrent writes: > > http://cr.openjdk.java.net/~bpb/8175209/webrev.03/ > > > Shall assume this is OK unless I hear otherwise. > Yes, go ahead. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Mar 8 20:46:12 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 8 Mar 2017 12:46:12 -0800 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: Message-ID: On Mar 8, 2017, at 8:10 AM, Alan Bateman wrote: >> To reduce the odds of this happening, this patch increases the pause time from 50 to 150 ms, an execution time increase for the test of 400 ms total as the method write1() is invoked four times. >> > This looks okay (longer is okay too) although it would be nice if there were a way to avoid the sleep. I created an alternative version http://cr.openjdk.java.net/~bpb/8176332/webrev.01/ which does not depend on the SocketChannel becoming readable after a fixed sleep. This passed regression tests on all the usual platforms. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From sybersnake at gmail.com Wed Mar 8 21:12:36 2017 From: sybersnake at gmail.com (Jon V.) Date: Wed, 8 Mar 2017 16:12:36 -0500 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: Message-ID: It makes me uneasy that there is this kind of blocking in SocketChannel to begin with. On Wed, Mar 8, 2017 at 3:46 PM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > On Mar 8, 2017, at 8:10 AM, Alan Bateman wrote: > > To reduce the odds of this happening, this patch increases the pause time > from 50 to 150 ms, an execution time increase for the test of 400 ms total > as the method write1() is invoked four times. > > This looks okay (longer is okay too) although it would be nice if there > were a way to avoid the sleep. > > > I created an alternative version http://cr.openjdk. > java.net/~bpb/8176332/webrev.01/ which does not depend on the > SocketChannel becoming readable after a fixed sleep. This passed regression > tests on all the usual platforms. > > Thanks, > > Brian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Mar 8 21:16:19 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 8 Mar 2017 13:16:19 -0800 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: Message-ID: <5A90590E-C8AE-4C4D-842C-AA6A479ED7AB@oracle.com> Hi Jon, What kind of blocking do you intend? Thanks, Brian On Mar 8, 2017, at 1:12 PM, Jon V. wrote: > It makes me uneasy that there is this kind of blocking in SocketChannel to begin with. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sybersnake at gmail.com Wed Mar 8 21:47:57 2017 From: sybersnake at gmail.com (Jon V.) Date: Wed, 8 Mar 2017 16:47:57 -0500 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: <5A90590E-C8AE-4C4D-842C-AA6A479ED7AB@oracle.com> References: <5A90590E-C8AE-4C4D-842C-AA6A479ED7AB@oracle.com> Message-ID: Thread.sleep is always going to go back to the kernel scheduler clock anyways. The kernel scheduler clock could be 1khz or 24hz; you shouldn't rely on it to perform timed operations this way. https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt Thread.sleep is a blocking operation. Sleeping a thread in order to wait for another thread or external action to be performed is not sound. Increasing the time may fix the bug reported but may also make a lot of existing working code much slower. I'd have to go find a stack trace and figure out exactly where this but it should probably be based on a mutex so it can continue immediately when the other thread operation completes. Doing so will fix the bug and other future cases where it takes a long time for the external action to occur as well as making it faster in situations where it takes only a few ms to perform. On Wed, Mar 8, 2017 at 4:16 PM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > Hi Jon, > > What kind of blocking do you intend? > > Thanks, > > Brian > > On Mar 8, 2017, at 1:12 PM, Jon V. wrote: > > It makes me uneasy that there is this kind of blocking in SocketChannel to > begin with. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Mar 8 21:52:58 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 8 Mar 2017 13:52:58 -0800 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: <5A90590E-C8AE-4C4D-842C-AA6A479ED7AB@oracle.com> Message-ID: Note that the sleep is only in the test, not the implementation code, and version .01 of the patch does not depend on a fixed total length of sleep but instead uses it only to pause before retrying. In almost all cases it should never have to retry and will not hit the sleep. If for some reason the loop continues indefinitely hitting the sleep, the test will time out. Brian On Mar 8, 2017, at 1:47 PM, Jon V. wrote: > Thread.sleep is always going to go back to the kernel scheduler clock anyways. The kernel scheduler clock could be 1khz or 24hz; you shouldn't rely on it to perform timed operations this way. https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt > > Thread.sleep is a blocking operation. Sleeping a thread in order to wait for another thread or external action to be performed is not sound. Increasing the time may fix the bug reported but may also make a lot of existing working code much slower. I'd have to go find a stack trace and figure out exactly where this but it should probably be based on a mutex so it can continue immediately when the other thread operation completes. Doing so will fix the bug and other future cases where it takes a long time for the external action to occur as well as making it faster in situations where it takes only a few ms to perform. > > On Wed, Mar 8, 2017 at 4:16 PM, Brian Burkhalter wrote: > Hi Jon, > > What kind of blocking do you intend? > > Thanks, > > Brian > > On Mar 8, 2017, at 1:12 PM, Jon V. wrote: > >> It makes me uneasy that there is this kind of blocking in SocketChannel to begin with. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sybersnake at gmail.com Wed Mar 8 22:02:17 2017 From: sybersnake at gmail.com (Jon V.) Date: Wed, 8 Mar 2017 17:02:17 -0500 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: <5A90590E-C8AE-4C4D-842C-AA6A479ED7AB@oracle.com> Message-ID: Oh duh! It was a/tests/ Can't believe I missed that. For a second there I thought this was in the main. I still wouldn't rely on the scheduler, maybe do a little loop with an counter using System.currentTimeMills? On Wed, Mar 8, 2017 at 4:52 PM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > Note that the sleep is only in the test, not the implementation code, and > version .01 of the patch does not depend on a fixed total length of sleep > but instead uses it only to pause before retrying. In almost all cases it > should never have to retry and will not hit the sleep. If for some reason > the loop continues indefinitely hitting the sleep, the test will time out. > > Brian > > > On Mar 8, 2017, at 1:47 PM, Jon V. wrote: > > Thread.sleep is always going to go back to the kernel scheduler clock > anyways. The kernel scheduler clock could be 1khz or 24hz; you shouldn't > rely on it to perform timed operations this way. > https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt > > Thread.sleep is a blocking operation. Sleeping a thread in order to wait > for another thread or external action to be performed is not sound. > Increasing the time may fix the bug reported but may also make a lot of > existing working code much slower. I'd have to go find a stack trace and > figure out exactly where this but it should probably be based on a mutex so > it can continue immediately when the other thread operation completes. > Doing so will fix the bug and other future cases where it takes a long time > for the external action to occur as well as making it faster in situations > where it takes only a few ms to perform. > > On Wed, Mar 8, 2017 at 4:16 PM, Brian Burkhalter < > brian.burkhalter at oracle.com> wrote: > >> Hi Jon, >> >> What kind of blocking do you intend? >> >> Thanks, >> >> Brian >> >> On Mar 8, 2017, at 1:12 PM, Jon V. wrote: >> >> It makes me uneasy that there is this kind of blocking in SocketChannel >> to begin with. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sybersnake at gmail.com Wed Mar 8 23:33:27 2017 From: sybersnake at gmail.com (Jon V.) Date: Wed, 8 Mar 2017 18:33:27 -0500 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: <5A90590E-C8AE-4C4D-842C-AA6A479ED7AB@oracle.com> Message-ID: Plus the current code doesn't properly deal with Interrupts and could give false-positives during automatic regression testing. On Wed, Mar 8, 2017 at 5:02 PM, Jon V. wrote: > Oh duh! It was a/tests/ Can't believe I missed that. For a second there > I thought this was in the main. > > I still wouldn't rely on the scheduler, maybe do a little loop with an > counter using System.currentTimeMills? > > On Wed, Mar 8, 2017 at 4:52 PM, Brian Burkhalter < > brian.burkhalter at oracle.com> wrote: > >> Note that the sleep is only in the test, not the implementation code, and >> version .01 of the patch does not depend on a fixed total length of sleep >> but instead uses it only to pause before retrying. In almost all cases it >> should never have to retry and will not hit the sleep. If for some reason >> the loop continues indefinitely hitting the sleep, the test will time out. >> >> Brian >> >> >> On Mar 8, 2017, at 1:47 PM, Jon V. wrote: >> >> Thread.sleep is always going to go back to the kernel scheduler clock >> anyways. The kernel scheduler clock could be 1khz or 24hz; you shouldn't >> rely on it to perform timed operations this way. >> https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt >> >> Thread.sleep is a blocking operation. Sleeping a thread in order to wait >> for another thread or external action to be performed is not sound. >> Increasing the time may fix the bug reported but may also make a lot of >> existing working code much slower. I'd have to go find a stack trace and >> figure out exactly where this but it should probably be based on a mutex so >> it can continue immediately when the other thread operation completes. >> Doing so will fix the bug and other future cases where it takes a long time >> for the external action to occur as well as making it faster in situations >> where it takes only a few ms to perform. >> >> On Wed, Mar 8, 2017 at 4:16 PM, Brian Burkhalter < >> brian.burkhalter at oracle.com> wrote: >> >>> Hi Jon, >>> >>> What kind of blocking do you intend? >>> >>> Thanks, >>> >>> Brian >>> >>> On Mar 8, 2017, at 1:12 PM, Jon V. wrote: >>> >>> It makes me uneasy that there is this kind of blocking in SocketChannel >>> to begin with. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu Mar 9 01:56:22 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 8 Mar 2017 17:56:22 -0800 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: Message-ID: Thanks for getting rid of all the flaky sleeps! I would sleep for less than 50ms on each retry. I suspect 1ms is typically enough. On Wed, Mar 8, 2017 at 12:46 PM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > On Mar 8, 2017, at 8:10 AM, Alan Bateman wrote: > > To reduce the odds of this happening, this patch increases the pause time > from 50 to 150 ms, an execution time increase for the test of 400 ms total > as the method write1() is invoked four times. > > This looks okay (longer is okay too) although it would be nice if there > were a way to avoid the sleep. > > > I created an alternative version http://cr.openjdk. > java.net/~bpb/8176332/webrev.01/ which does not depend on the > SocketChannel becoming readable after a fixed sleep. This passed regression > tests on all the usual platforms. > > Thanks, > > Brian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Mar 9 02:00:03 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 8 Mar 2017 18:00:03 -0800 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: Message-ID: <63D376FD-3C41-4458-8B05-C1ED482B0C4F@oracle.com> On Mar 8, 2017, at 5:56 PM, Martin Buchholz wrote: > Thanks for getting rid of all the flaky sleeps! :-) > I would sleep for less than 50ms on each retry. I suspect 1ms is typically enough. You might be right. With the version in the JDK tree I could never reproduce the problem. I actually think this sleep will almost never happen, i.e., one byte will be read on the first try. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Mar 9 11:43:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Mar 2017 11:43:58 +0000 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: Message-ID: On 08/03/2017 20:46, Brian Burkhalter wrote: > On Mar 8, 2017, at 8:10 AM, Alan Bateman > wrote: > >>> To reduce the odds of this happening, this patch increases the pause >>> time from 50 to 150 ms, an execution time increase for the test of >>> 400 ms total as the method write1() is invoked four times. >>> >> This looks okay (longer is okay too) although it would be nice if >> there were a way to avoid the sleep. > > I created an alternative version > http://cr.openjdk.java.net/~bpb/8176332/webrev.01/ > which does not > depend on the SocketChannel becoming readable after a fixed sleep. > This passed regression tests on all the usual platforms. > This changes the test in a subtle way but I think it is okay. Can you fix the formatting of L58-59 before you push this? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Mar 9 11:46:17 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Mar 2017 11:46:17 +0000 Subject: JDK 9 RFR of 8176237: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores In-Reply-To: <01DDC5DD-AC32-4325-81F5-F31AA60581B7@oracle.com> References: <01DDC5DD-AC32-4325-81F5-F31AA60581B7@oracle.com> Message-ID: <0002ef56-8ae1-248a-da56-ac5b5c637ec6@oracle.com> On 07/03/2017 00:28, Brian Burkhalter wrote: > Please review a patch for this test issue: > > Issue:https://bugs.openjdk.java.net/browse/JDK-8176237 > Patch:http://javaweb.us.oracle.com/~bburkhal/jdk9/review/8176237/webrev.00/ > > > Similar to the change previously submitted in the patch for [1], > attempt to access the FileStore enumeration only if ?df? does not hang > (Unix-only). Also move the ?df? file system accessibility test code to > jdk.testlibrary.FileUtils#areFileSystemsAccessible. > Looks okay but FileUtils.areFileSystemsAccessible() needs a comment so that future users of this test infrastructure have something to read. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Mar 9 12:30:24 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 9 Mar 2017 12:30:24 +0000 Subject: JDK 9 RFR of 8176237: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores In-Reply-To: <0002ef56-8ae1-248a-da56-ac5b5c637ec6@oracle.com> References: <01DDC5DD-AC32-4325-81F5-F31AA60581B7@oracle.com> <0002ef56-8ae1-248a-da56-ac5b5c637ec6@oracle.com> Message-ID: <78FA5D44-D9A9-44CC-8B2F-8873547EAE25@oracle.com> > On 9 Mar 2017, at 11:46, Alan Bateman wrote: > > > > On 07/03/2017 00:28, Brian Burkhalter wrote: >> Please review a patch for this test issue: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8176237 >> Patch: http://javaweb.us.oracle.com/~bburkhal/jdk9/review/8176237/webrev.00/ >> >> Similar to the change previously submitted in the patch for [1], attempt to access the FileStore enumeration only if ?df? does not hang (Unix-only). Also move the ?df? file system accessibility test code to jdk.testlibrary.FileUtils#areFileSystemsAccessible. >> > Looks okay but FileUtils.areFileSystemsAccessible() needs a comment so that future users of this test infrastructure have something to read. Also, FileUtils already has a field, `isWindows`, that can be used rather than re-reading the `os.name` system property. -Chris. From brian.burkhalter at oracle.com Thu Mar 9 15:54:25 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 9 Mar 2017 07:54:25 -0800 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: Message-ID: On Mar 9, 2017, at 3:43 AM, Alan Bateman wrote: > This changes the test in a subtle way but I think it is okay. Can you fix the formatting of L58-59 before you push this? Do you mean like A or B below? B overruns 80 columns. Thanks, Brian === A === --- a/test/java/nio/channels/Selector/ChangingInterests.java +++ b/test/java/nio/channels/Selector/ChangingInterests.java @@ -55,8 +55,8 @@ * Writes two bytes to 'out' and reads one byte from 'in' so * as to make 'in' readable. */ - static void makeReadable(SocketChannel out, SocketChannel in) - throws IOException { + static void makeReadable(SocketChannel out, + SocketChannel in) throws IOException { === B === --- a/test/java/nio/channels/Selector/ChangingInterests.java +++ b/test/java/nio/channels/Selector/ChangingInterests.java @@ -55,8 +55,7 @@ * Writes two bytes to 'out' and reads one byte from 'in' so * as to make 'in' readable. */ - static void makeReadable(SocketChannel out, SocketChannel in) - throws IOException { + static void makeReadable(SocketChannel out, SocketChannel in) throws IOException { -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Mar 9 15:55:23 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Mar 2017 15:55:23 +0000 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: Message-ID: On 09/03/2017 15:54, Brian Burkhalter wrote: > > On Mar 9, 2017, at 3:43 AM, Alan Bateman > wrote: > >> This changes the test in a subtle way but I think it is okay. Can you >> fix the formatting of L58-59 before you push this? > > Do you mean like A or B below? B overruns 80 columns. B is easier to read. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Mar 9 16:22:08 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 9 Mar 2017 08:22:08 -0800 Subject: JDK 9 RFR of 8176237: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores In-Reply-To: <78FA5D44-D9A9-44CC-8B2F-8873547EAE25@oracle.com> References: <01DDC5DD-AC32-4325-81F5-F31AA60581B7@oracle.com> <0002ef56-8ae1-248a-da56-ac5b5c637ec6@oracle.com> <78FA5D44-D9A9-44CC-8B2F-8873547EAE25@oracle.com> Message-ID: On Mar 9, 2017, at 4:30 AM, Chris Hegarty wrote: >> Looks okay but FileUtils.areFileSystemsAccessible() needs a comment so that future users of this test infrastructure have something to read. > > Also, FileUtils already has a field, `isWindows`, that can be used > rather than re-reading the `os.name` system property. OK I?ve made these two changes in http://cr.openjdk.java.net/~bpb/8176237/webrev.01/ The difference with webrev.00 is included below. Thanks, Brian --- a/test/lib/testlibrary/jdk/testlibrary/FileUtils.java +++ b/test/lib/testlibrary/jdk/testlibrary/FileUtils.java @@ -192,19 +192,27 @@ return excs; } + /** + * Checks whether all file systems are accessible. This is performed + * by checking free disk space on all mounted file systems via a + * separate, spawned process. File systems are considered to be + * accessible if this process completes successfully before a given + * fixed duration has elapsed. + * + * @implNote On Unix this executes the {@code df} command in a separate + * process and on Windows always returns {@code true}. + */ public static boolean areFileSystemsAccessible() throws IOException { boolean areFileSystemsAccessible = true; - if (!System.getProperty("os.name").equals("Windows")) { + if (!isWindows) { // try to check whether 'df' hangs - System.out.println("\n--- Begin df output ---"); + System.out.println("\n--- df output ---"); System.out.flush(); Process proc = new ProcessBuilder("df").inheritIO().start(); try { proc.waitFor(90, TimeUnit.SECONDS); } catch (InterruptedException ignored) { } - System.out.println("--- End df output ---\n"); - System.out.flush(); -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Mar 9 16:23:22 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Mar 2017 16:23:22 +0000 Subject: JDK 9 RFR of 8176237: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores In-Reply-To: References: <01DDC5DD-AC32-4325-81F5-F31AA60581B7@oracle.com> <0002ef56-8ae1-248a-da56-ac5b5c637ec6@oracle.com> <78FA5D44-D9A9-44CC-8B2F-8873547EAE25@oracle.com> Message-ID: <507fbb82-cc43-57a1-e30c-8f3f7bc10049@oracle.com> Looks good. On 09/03/2017 16:22, Brian Burkhalter wrote: > On Mar 9, 2017, at 4:30 AM, Chris Hegarty > wrote: > >>> Looks okay but FileUtils.areFileSystemsAccessible() needs a comment >>> so that future users of this test infrastructure have something to read. >> >> Also, FileUtils already has a field, `isWindows`, that can be used >> rather than re-reading the `os.name` system property. > > OK I?ve made these two changes in > > http://cr.openjdk.java.net/~bpb/8176237/webrev.01/ > > > The difference with webrev.00 is included below. > > Thanks, > > Brian > > --- a/test/lib/testlibrary/jdk/testlibrary/FileUtils.java > +++ b/test/lib/testlibrary/jdk/testlibrary/FileUtils.java > @@ -192,19 +192,27 @@ > return excs; > } > > > + /** > + * Checks whether all file systems are accessible. This is performed > + * by checking free disk space on all mounted file systems via a > + * separate, spawned process. File systems are considered to be > + * accessible if this process completes successfully before a given > + * fixed duration has elapsed. > + * > + * @implNote On Unix this executes the {@code df} command in a > separate > + * process and on Windows always returns {@code true}. > + */ > public static boolean areFileSystemsAccessible() throws IOException { > boolean areFileSystemsAccessible = true; > - if (!System.getProperty("os.name").equals("Windows")) { > + if (!isWindows) { > // try to check whether 'df' hangs > - System.out.println("\n--- Begin df output ---"); > + System.out.println("\n--- df output ---"); > System.out.flush(); > Process proc = new ProcessBuilder("df").inheritIO().start(); > try { > proc.waitFor(90, TimeUnit.SECONDS); > } catch (InterruptedException ignored) { > } > - System.out.println("--- End df output ---\n"); > - System.out.flush(); -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Mar 9 16:52:17 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 9 Mar 2017 16:52:17 +0000 Subject: JDK 9 RFR of 8176237: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores In-Reply-To: References: <01DDC5DD-AC32-4325-81F5-F31AA60581B7@oracle.com> <0002ef56-8ae1-248a-da56-ac5b5c637ec6@oracle.com> <78FA5D44-D9A9-44CC-8B2F-8873547EAE25@oracle.com> Message-ID: <79D44358-A010-440A-A98E-A217132F81B5@oracle.com> Thanks Brian. +1 -Chris. > On 9 Mar 2017, at 16:22, Brian Burkhalter wrote: > > On Mar 9, 2017, at 4:30 AM, Chris Hegarty wrote: > >>> Looks okay but FileUtils.areFileSystemsAccessible() needs a comment so that future users of this test infrastructure have something to read. >> >> Also, FileUtils already has a field, `isWindows`, that can be used >> rather than re-reading the `os.name` system property. > > OK I?ve made these two changes in > > http://cr.openjdk.java.net/~bpb/8176237/webrev.01/ > > The difference with webrev.00 is included below. > > Thanks, > > Brian > > --- a/test/lib/testlibrary/jdk/testlibrary/FileUtils.java > +++ b/test/lib/testlibrary/jdk/testlibrary/FileUtils.java > @@ -192,19 +192,27 @@ > return excs; > } > > + /** > + * Checks whether all file systems are accessible. This is performed > + * by checking free disk space on all mounted file systems via a > + * separate, spawned process. File systems are considered to be > + * accessible if this process completes successfully before a given > + * fixed duration has elapsed. > + * > + * @implNote On Unix this executes the {@code df} command in a separate > + * process and on Windows always returns {@code true}. > + */ > public static boolean areFileSystemsAccessible() throws IOException { > boolean areFileSystemsAccessible = true; > - if (!System.getProperty("os.name").equals("Windows")) { > + if (!isWindows) { > // try to check whether 'df' hangs > - System.out.println("\n--- Begin df output ---"); > + System.out.println("\n--- df output ---"); > System.out.flush(); > Process proc = new ProcessBuilder("df").inheritIO().start(); > try { > proc.waitFor(90, TimeUnit.SECONDS); > } catch (InterruptedException ignored) { > } > - System.out.println("--- End df output ---\n"); > - System.out.flush(); From brian.burkhalter at oracle.com Thu Mar 9 16:57:03 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 9 Mar 2017 08:57:03 -0800 Subject: JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1() In-Reply-To: References: Message-ID: <7F6C01BF-4575-4036-A680-D35A6B44B92D@oracle.com> On Mar 9, 2017, at 7:55 AM, Alan Bateman wrote: >>> This changes the test in a subtle way but I think it is okay. Can you fix the formatting of L58-59 before you push this? >> >> Do you mean like A or B below? B overruns 80 columns. > B is easier to read. So changed and pushed. Final version: http://cr.openjdk.java.net/~bpb/8176332/webrev.02/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Mar 13 11:33:59 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 Mar 2017 11:33:59 +0000 Subject: Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError? In-Reply-To: References: Message-ID: <58ad34a7-80f2-2f85-cc2d-165612bf8076@oracle.com> Anthony, Many of the Collection types throw OOME if requested to grow greater than ~2GB. Likewise some operations of String and StringBuilder. Though this behavior is not strictly part of the current specification, I suspect that it is the defacto standard ( since the implementation has always behaved this way ). The java.lang.module.ModuleReader::read method is another method that specifies the behavior if the returned type is not capable of supporting very large amounts of data. I agree that the use of OOME here is somewhat overloaded, but it appears that we already well down this path, best to make it clear and consistent in the spec. -Chris. On 12/03/17 14:24, Anthony Vanelverdinghe wrote: > Files::readAllBytes is specified to throw an OutOfMemoryError "if an > array of the required size cannot be allocated, for example the file is > larger that 2G". Now in Java 9, InputStream::readAllBytes does the same. > > However, this overloads the meaning of OutOfMemoryError: either "the JVM > is out of memory" or "the resultant array would require long-based > indices". > > In my opinion, this overloading is problematic, because: > - OutOfMemoryError has very clear semantics, and I don't see the link > between OOME and the fact that a resultant byte[] would need to be >2G. > If I have 5G of free heap space, and try to read a 3G file, I'd expect > something like an UnsupportedOperationException, but definitely not an > OutOfMemoryError. > - the former meaning is an actual Error, whereas the latter is an > Exception from which the application can recover. > - developers might be tempted to catch the OOME and retry to read the > file/input stream in chunks, no matter the cause of the OOME. > > What was the rationale for using OutOfMemory here? And would it still be > possible to change this before Rampdown Phase 2? > > Kind regards, > Anthony > > From peter.levart at gmail.com Mon Mar 13 11:52:20 2017 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 13 Mar 2017 12:52:20 +0100 Subject: Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError? In-Reply-To: <58ad34a7-80f2-2f85-cc2d-165612bf8076@oracle.com> References: <58ad34a7-80f2-2f85-cc2d-165612bf8076@oracle.com> Message-ID: On 03/13/2017 12:33 PM, Chris Hegarty wrote: > Anthony, > > Many of the Collection types throw OOME if requested to grow > greater than ~2GB. Likewise some operations of String and > StringBuilder. Though this behavior is not strictly part of > the current specification, I suspect that it is the defacto > standard ( since the implementation has always behaved this > way ). > > The java.lang.module.ModuleReader::read method is another > method that specifies the behavior if the returned type is > not capable of supporting very large amounts of data. > > I agree that the use of OOME here is somewhat overloaded, but > it appears that we already well down this path, best to make > it clear and consistent in the spec. What about (talking about JDK10 of course) creating OutOfMemoryError subclasses to cover cases that don't pertain to Java heap memory? Regards, Peter > > -Chris. > > On 12/03/17 14:24, Anthony Vanelverdinghe wrote: >> Files::readAllBytes is specified to throw an OutOfMemoryError "if an >> array of the required size cannot be allocated, for example the file is >> larger that 2G". Now in Java 9, InputStream::readAllBytes does the same. >> >> However, this overloads the meaning of OutOfMemoryError: either "the JVM >> is out of memory" or "the resultant array would require long-based >> indices". >> >> In my opinion, this overloading is problematic, because: >> - OutOfMemoryError has very clear semantics, and I don't see the link >> between OOME and the fact that a resultant byte[] would need to be >2G. >> If I have 5G of free heap space, and try to read a 3G file, I'd expect >> something like an UnsupportedOperationException, but definitely not an >> OutOfMemoryError. >> - the former meaning is an actual Error, whereas the latter is an >> Exception from which the application can recover. >> - developers might be tempted to catch the OOME and retry to read the >> file/input stream in chunks, no matter the cause of the OOME. >> >> What was the rationale for using OutOfMemory here? And would it still be >> possible to change this before Rampdown Phase 2? >> >> Kind regards, >> Anthony >> >> From brian.burkhalter at oracle.com Tue Mar 14 16:47:05 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 14 Mar 2017 09:47:05 -0700 Subject: JDK 9 RFR of 8176744: Improve internal timing of java/nio/channels/Selector/SelectAndClose.java Message-ID: <30CF1D64-35DD-4CCE-BE28-850FF6750B3E@oracle.com> Please review this test-only fix at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8176744 Patch: http://cr.openjdk.java.net/~bpb/8176744/webrev.00/ Deal with another flaky use of sleep(). Thanks, Brian From roger.riggs at oracle.com Tue Mar 14 20:24:53 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 14 Mar 2017 16:24:53 -0400 Subject: JDK 9 RFR of 8176744: Improve internal timing of java/nio/channels/Selector/SelectAndClose.java In-Reply-To: <30CF1D64-35DD-4CCE-BE28-850FF6750B3E@oracle.com> References: <30CF1D64-35DD-4CCE-BE28-850FF6750B3E@oracle.com> Message-ID: <2736dfc4-ae97-aa77-8b5c-91e005f9b917@oracle.com> Hi Brian, Should awakened and closed be volatile since they are read and written by different threads? The countdown latch part is fine. Roger On 3/14/17 12:47 PM, Brian Burkhalter wrote: > Please review this test-only fix at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8176744 > Patch: http://cr.openjdk.java.net/~bpb/8176744/webrev.00/ > > Deal with another flaky use of sleep(). > > Thanks, > > Brian From Alan.Bateman at oracle.com Tue Mar 14 20:31:12 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Mar 2017 20:31:12 +0000 Subject: JDK 9 RFR of 8176744: Improve internal timing of java/nio/channels/Selector/SelectAndClose.java In-Reply-To: <30CF1D64-35DD-4CCE-BE28-850FF6750B3E@oracle.com> References: <30CF1D64-35DD-4CCE-BE28-850FF6750B3E@oracle.com> Message-ID: On 14/03/2017 16:47, Brian Burkhalter wrote: > Please review this test-only fix at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8176744 > Patch: http://cr.openjdk.java.net/~bpb/8176744/webrev.00/ > > Deal with another flaky use of sleep(). > Mostly, it's still possible that 500ms isn't sufficient for select to block when the machine is overloaded with concurrent tests. So you could bump that up a bit. I agree with Roger on "awakened" and "closed", they should be volatile. -Alan From brian.burkhalter at oracle.com Tue Mar 14 20:39:35 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 14 Mar 2017 13:39:35 -0700 Subject: JDK 9 RFR of 8176744: Improve internal timing of java/nio/channels/Selector/SelectAndClose.java In-Reply-To: References: <30CF1D64-35DD-4CCE-BE28-850FF6750B3E@oracle.com> Message-ID: Hi Roger, Alan, On Mar 14, 2017, at 1:31 PM, Alan Bateman wrote: > On 14/03/2017 16:47, Brian Burkhalter wrote: >> Please review this test-only fix at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8176744 >> Patch: http://cr.openjdk.java.net/~bpb/8176744/webrev.00/ >> >> Deal with another flaky use of sleep(). >> > Mostly, it's still possible that 500ms isn't sufficient for select to block when the machine is overloaded with concurrent tests. So you could bump that up a bit. I agree with Roger on "awakened" and "closed", they should be volatile. Here?s an updated version: http://cr.openjdk.java.net/~bpb/8176744/webrev.01/ Thanks, Brian From Alan.Bateman at oracle.com Tue Mar 14 20:40:33 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Mar 2017 20:40:33 +0000 Subject: JDK 9 RFR of 8176744: Improve internal timing of java/nio/channels/Selector/SelectAndClose.java In-Reply-To: References: <30CF1D64-35DD-4CCE-BE28-850FF6750B3E@oracle.com> Message-ID: <6ffda186-0ece-0687-e7b0-713e017c214a@oracle.com> On 14/03/2017 20:39, Brian Burkhalter wrote: > > Here?s an updated version: > > http://cr.openjdk.java.net/~bpb/8176744/webrev.01/ > > Looks okay to me. From roger.riggs at oracle.com Tue Mar 14 20:42:19 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 14 Mar 2017 16:42:19 -0400 Subject: JDK 9 RFR of 8176744: Improve internal timing of java/nio/channels/Selector/SelectAndClose.java In-Reply-To: <6ffda186-0ece-0687-e7b0-713e017c214a@oracle.com> References: <30CF1D64-35DD-4CCE-BE28-850FF6750B3E@oracle.com> <6ffda186-0ece-0687-e7b0-713e017c214a@oracle.com> Message-ID: <8469ccac-9ab0-fbd4-6b2a-7ef7e7215fb0@oracle.com> +1 On 3/14/17 4:40 PM, Alan Bateman wrote: > > > On 14/03/2017 20:39, Brian Burkhalter wrote: >> >> Here?s an updated version: >> >> http://cr.openjdk.java.net/~bpb/8176744/webrev.01/ >> >> > Looks okay to me. From brian.burkhalter at oracle.com Thu Mar 16 02:23:51 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 15 Mar 2017 19:23:51 -0700 Subject: JDK 9 RFR of 8176846: (fc) Increase timeouts of and instrument some tests using FileChannel#write Message-ID: <0E108174-2D1A-4DC1-B4CA-9DCC7F20F958@oracle.com> Please review this test-only change. Issue: https://bugs.openjdk.java.net/browse/JDK-8176846 Patch: http://cr.openjdk.java.net/~bpb/8176846/webrev.00/ Set the timeouts of the four tests to 300 sec (5 min.) and print to stdout the time taken to perform some large FileChannel#writes. Thanks, Brian From christoph.langer at sap.com Thu Mar 16 09:25:03 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 16 Mar 2017 09:25:03 +0000 Subject: JDK 9 RFR of 8176846: (fc) Increase timeouts of and instrument some tests using FileChannel#write In-Reply-To: <0E108174-2D1A-4DC1-B4CA-9DCC7F20F958@oracle.com> References: <0E108174-2D1A-4DC1-B4CA-9DCC7F20F958@oracle.com> Message-ID: Hi Brian, looks reasonable to me. Reviewed. Best regards Christoph > -----Original Message----- > From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of > Brian Burkhalter > Sent: Donnerstag, 16. M?rz 2017 03:24 > To: nio-dev > Subject: JDK 9 RFR of 8176846: (fc) Increase timeouts of and instrument some > tests using FileChannel#write > > Please review this test-only change. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8176846 > Patch: http://cr.openjdk.java.net/~bpb/8176846/webrev.00/ > > Set the timeouts of the four tests to 300 sec (5 min.) and print to stdout the > time taken to perform some large FileChannel#writes. > > Thanks, > > Brian From Roger.Riggs at Oracle.com Thu Mar 16 13:13:51 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 16 Mar 2017 09:13:51 -0400 Subject: JDK 9 RFR of 8176846: (fc) Increase timeouts of and instrument some tests using FileChannel#write In-Reply-To: References: <0E108174-2D1A-4DC1-B4CA-9DCC7F20F958@oracle.com> Message-ID: +1 On 3/16/2017 5:25 AM, Langer, Christoph wrote: > Hi Brian, > > looks reasonable to me. Reviewed. > > Best regards > Christoph > >> -----Original Message----- >> From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of >> Brian Burkhalter >> Sent: Donnerstag, 16. M?rz 2017 03:24 >> To: nio-dev >> Subject: JDK 9 RFR of 8176846: (fc) Increase timeouts of and instrument some >> tests using FileChannel#write >> >> Please review this test-only change. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8176846 >> Patch: http://cr.openjdk.java.net/~bpb/8176846/webrev.00/ >> >> Set the timeouts of the four tests to 300 sec (5 min.) and print to stdout the >> time taken to perform some large FileChannel#writes. >> >> Thanks, >> >> Brian From brian.burkhalter at oracle.com Thu Mar 16 20:50:32 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 16 Mar 2017 13:50:32 -0700 Subject: JDK 9 RFR of 8176895: (fc) Split java/nio/channels/FileChannel/Transfer.java into smaller tests Message-ID: <43BF5782-85E7-402F-AB53-93890EA65642@oracle.com> Please review this test-only change. Issue: https://bugs.openjdk.java.net/browse/JDK-8176895 Patch: http://cr.openjdk.java.net/~bpb/8176895/webrev.00/ Split the test in three, moving two sub-tests which write 4 GB files to one test, one sub-test which writes a 6 GB file to another test, leaving the remaining sub-tests in the original test. This should further reduce the probability of spurious failures due to a slow filesystem. Thanks, Brian From christoph.langer at sap.com Fri Mar 17 07:39:53 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 17 Mar 2017 07:39:53 +0000 Subject: JDK 9 RFR of 8176895: (fc) Split java/nio/channels/FileChannel/Transfer.java into smaller tests In-Reply-To: <43BF5782-85E7-402F-AB53-93890EA65642@oracle.com> References: <43BF5782-85E7-402F-AB53-93890EA65642@oracle.com> Message-ID: Hi Brian, this change makes sense to me. +1. Best regards Christoph > -----Original Message----- > From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of > Brian Burkhalter > Sent: Donnerstag, 16. M?rz 2017 21:51 > To: nio-dev > Subject: JDK 9 RFR of 8176895: (fc) Split > java/nio/channels/FileChannel/Transfer.java into smaller tests > > Please review this test-only change. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8176895 > Patch: http://cr.openjdk.java.net/~bpb/8176895/webrev.00/ > > Split the test in three, moving two sub-tests which write 4 GB files to one > test, one sub-test which writes a 6 GB file to another test, leaving the > remaining sub-tests in the original test. This should further reduce the > probability of spurious failures due to a slow filesystem. > > Thanks, > > Brian From weijun.wang at oracle.com Tue Mar 21 14:47:14 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Mar 2017 22:47:14 +0800 Subject: Compare a Path to a string In-Reply-To: References: Message-ID: <2095b1cb-72c8-0df0-7497-5ac7cb6b55e8@oracle.com> I'm profiling the new FilePermission implementation and found a lot of time spending on comparing a Path to a string (in fact, toString()), and in every case the path has only one element. Here are them: 1. Comparing with "-": Path lastName = npath.getFileName(); if (lastName != null && lastName.toString().equals("-")) { ... } 2. Comparing with "": p = p2.relativize(p1).normalize(); if (p.getName(0).toString().isEmpty()) { ... } 3. Comparing with "..": for (Path item: p) { String s = item.toString(); if (!s.equals("..")) { ... } } Maybe it's better to compare them with static final Path fields? I create some benchmarks and they show comparing with objects is better than comparing with strings, the throughput is roughly 40% higher. I am using linux-x64. So I made one enhancement to UnixPath.(fs, str) to store normalizeAndCheck(str) (it is calculated anyway) as stringValue (which will be returned by toString) in the constructor, and seems comparing with objects and comparing with strings have no significant difference now. I admit I haven't analyzed if normalizeAndCheck(str) is always the correct toString() result. Is there a better way? Thanks Max From brian.burkhalter at oracle.com Fri Mar 24 16:07:48 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 24 Mar 2017 09:07:48 -0700 Subject: JDK 9 RFR of 8177550: (fc) Enable java/nio/channels/FileChannel/{Transfer4GBFile.java, TransferTo6GBFile.java} on Linux and Windows Message-ID: <207009E1-6650-4FAD-99BD-3312A83EB60A@oracle.com> Please review this test-only change at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8177550 Patch: http://cr.openjdk.java.net/~bpb/8177550/webrev.00/ The test Transfer.java was recently split into three tests and the timeout for all three increased. Therefore we should try re-enabling these tests where they are suppressed on Linux and Windows. Thanks, Brian From Alan.Bateman at oracle.com Fri Mar 24 16:13:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Mar 2017 16:13:06 +0000 Subject: JDK 9 RFR of 8177550: (fc) Enable java/nio/channels/FileChannel/{Transfer4GBFile.java, TransferTo6GBFile.java} on Linux and Windows In-Reply-To: <207009E1-6650-4FAD-99BD-3312A83EB60A@oracle.com> References: <207009E1-6650-4FAD-99BD-3312A83EB60A@oracle.com> Message-ID: <0e7046b8-b095-fe16-ec5f-9d955470316a@oracle.com> On 24/03/2017 16:07, Brian Burkhalter wrote: > Please review this test-only change at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8177550 > Patch: http://cr.openjdk.java.net/~bpb/8177550/webrev.00/ > > The test Transfer.java was recently split into three tests and the timeout for all three increased. Therefore we should try re-enabling these tests where they are suppressed on Linux and Windows. > > Looks good. -Alan From brian.burkhalter at oracle.com Fri Mar 24 20:06:17 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 24 Mar 2017 13:06:17 -0700 Subject: JDK 9 RFR of 8177559: Enable java/nio/channels/Selector/OutOfBand.java for macOS >= 10.10.5 Message-ID: <6BC3F62B-2AB4-4E7F-916C-995019C7EAA1@oracle.com> Please review this test-only change at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8177559 Patch: http://cr.openjdk.java.net/~bpb/8177559/webrev.00/ Recent testing as list in [1] and elsewhere has revealed that the underlying OS X problem appears to have been fixed at least for Darwin kernels of version 14.5 or newer which corresponds to macOS 10.10.5 or newer. This change modifies the test to require either a non-macOS operating system or a macOS version of 10.10.5 or newer. The test is also removed from the problem list. If the recent tests are spurious and the test ends up failing again it can be re-listed as a problem. If it continues to succeed then [1] can then later be resolved as Cannot Reproduce once we are sure. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-7132677 From brian.burkhalter at oracle.com Fri Mar 24 21:31:35 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 24 Mar 2017 14:31:35 -0700 Subject: JDK 9 RFR of 8177564: Remove check for Windows XP and Server 2003 in java/nio/channels/DatagramChannel/NetworkConfiguration.java Message-ID: <18ED96BD-EE73-4ACF-A0DA-EDD9003963F1@oracle.com> Please review this test-only change at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8177564 Patch: http://cr.openjdk.java.net/~bpb/8177564/webrev.00/ As Windows XP and Server 2003 are no longer supported by Java there is no point in checking for them in order to determine IPv6 capability. Thanks, Brian From brian.burkhalter at oracle.com Fri Mar 24 21:38:11 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 24 Mar 2017 14:38:11 -0700 Subject: JDK 9 RFR of 8177565: java/nio/channels/Selector/SelectorLimit.java disabled for Windows release >= 6.0 Message-ID: Please review this test-only issue at your convenience. Issue: XXX Patch: [1] It appears as if this test was intended to disable Windows ME and Windows 95 and older but was never updated to run on Windows Vista and newer so is in effect has been a no-op in all recent regression testing. The test has been verified to pass on Windows 8.1 x64. Thanks, Brian [1] diff --- a/test/java/nio/channels/Selector/SelectorLimit.java +++ b/test/java/nio/channels/Selector/SelectorLimit.java @@ -66,15 +66,6 @@ static final int MIN_KEYS = 100; public static void main(String[] args) throws Exception { - // win9X can't handle many connections at once - String osName = System.getProperty("os.name"); - if (osName.toLowerCase().startsWith("win")) { - if (!(osName.equals("Windows NT") - || osName.equals("Windows 2000") - || osName.equals("Windows XP"))) - return; - } -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Mar 24 21:39:47 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 24 Mar 2017 14:39:47 -0700 Subject: JDK 9 RFR of 8177565: java/nio/channels/Selector/SelectorLimit.java disabled for Windows release >= 6.0 In-Reply-To: References: Message-ID: Forgot to update the issue link: https://bugs.openjdk.java.net/browse/JDK-8177565 Brian On Mar 24, 2017, at 2:38 PM, Brian Burkhalter wrote: > Issue: XXX -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Mar 24 21:44:07 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Mar 2017 21:44:07 +0000 Subject: JDK 9 RFR of 8177564: Remove check for Windows XP and Server 2003 in java/nio/channels/DatagramChannel/NetworkConfiguration.java In-Reply-To: <18ED96BD-EE73-4ACF-A0DA-EDD9003963F1@oracle.com> References: <18ED96BD-EE73-4ACF-A0DA-EDD9003963F1@oracle.com> Message-ID: <099c54de-0f73-f02d-4620-5b2bdbdee5e2@oracle.com> On 24/03/2017 21:31, Brian Burkhalter wrote: > Please review this test-only change at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8177564 > Patch: http://cr.openjdk.java.net/~bpb/8177564/webrev.00/ > > As Windows XP and Server 2003 are no longer supported by Java there is no point in checking for them in order to determine IPv6 capability. > Looks good. From Alan.Bateman at oracle.com Fri Mar 24 21:44:37 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Mar 2017 21:44:37 +0000 Subject: JDK 9 RFR of 8177565: java/nio/channels/Selector/SelectorLimit.java disabled for Windows release >= 6.0 In-Reply-To: References: Message-ID: <67342307-b97e-fc43-9040-0127e79725ab@oracle.com> On 24/03/2017 21:38, Brian Burkhalter wrote: > Please review this test-only issue at your convenience. > > Issue:XXX > Patch:[1] > > It appears as if this test was intended to disable Windows ME and > Windows 95 and older but was never updated to run on Windows Vista and > newer so is in effect has been a no-op in all recent regression > testing. The test has been verified to pass on Windows 8.1 x64. > > A JDK 1.4 era test I think, the change looks good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.marschall at gmail.com Sun Mar 26 10:44:01 2017 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Sun, 26 Mar 2017 12:44:01 +0200 Subject: normalization changes in APFS Message-ID: Hello In APFS, likely shipping with macOS 10.13, file names are not longer stored in nfd [1]. The behaviour now seems very similar to Linux. That means it's possible to have different two files names in the same folder that normalize to the same name. AFAIK currently nfd->nfc conversion happens in the Java NIO file system layer (JDK-7130915). It may make sense to revisit that. [1] http://mjtsai.com/blog/2017/03/24/apfss-bag-of-bytes-filenames/ Cheers Philippe From amy.lu at oracle.com Mon Mar 27 02:27:49 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 27 Mar 2017 10:27:49 +0800 Subject: JDK 9 RFR of 8177559: Enable java/nio/channels/Selector/OutOfBand.java for macOS >= 10.10.5 In-Reply-To: <6BC3F62B-2AB4-4E7F-916C-995019C7EAA1@oracle.com> References: <6BC3F62B-2AB4-4E7F-916C-995019C7EAA1@oracle.com> Message-ID: <691537cd-7312-3394-749a-a790307f5c74@oracle.com> On 3/25/17 4:06 AM, Brian Burkhalter wrote: > Please review this test-only change at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8177559 > Patch: http://cr.openjdk.java.net/~bpb/8177559/webrev.00/ This makes test still run at 10.10 ... 10.10.4 How about : * @requires (os.family != "mac") * | ((os.simpleVersion == "10.10") & (os.version == "10.10.5")) * | ((os.simpleVersion != "10.10") & (os.simpleVersion != "10.9") & (os.simpleVersion != "10.8")) (I'm not a reviewer.) Thanks, Amy > Recent testing as list in [1] and elsewhere has revealed that the underlying OS X problem appears to have been fixed at least for Darwin kernels of version 14.5 or newer which corresponds to macOS 10.10.5 or newer. This change modifies the test to require either a non-macOS operating system or a macOS version of 10.10.5 or newer. The test is also removed from the problem list. If the recent tests are spurious and the test ends up failing again it can be re-listed as a problem. If it continues to succeed then [1] can then later be resolved as Cannot Reproduce once we are sure. > > Thanks, > > Brian > > [1]https://bugs.openjdk.java.net/browse/JDK-7132677 From brian.burkhalter at oracle.com Mon Mar 27 15:36:37 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 27 Mar 2017 08:36:37 -0700 Subject: JDK 9 RFR of 8177559: Enable java/nio/channels/Selector/OutOfBand.java for macOS >= 10.10.5 In-Reply-To: <691537cd-7312-3394-749a-a790307f5c74@oracle.com> References: <6BC3F62B-2AB4-4E7F-916C-995019C7EAA1@oracle.com> <691537cd-7312-3394-749a-a790307f5c74@oracle.com> Message-ID: <91E05DEA-7A6F-4579-8468-4B6676F60FAC@oracle.com> Hi Amy, On Mar 26, 2017, at 7:27 PM, Amy Lu wrote: > On 3/25/17 4:06 AM, Brian Burkhalter wrote: >> Please review this test-only change at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8177559 >> Patch: http://cr.openjdk.java.net/~bpb/8177559/webrev.00/ > > This makes test still run at 10.10 ? 10.10.4 Do you know whether it passes on any 10.x before 10.10.5? > How about : > > * @requires (os.family != "mac") > * | ((os.simpleVersion == "10.10") & (os.version == "10.10.5")) > * | ((os.simpleVersion != "10.10") & (os.simpleVersion != "10.9") & (os.simpleVersion != "10.8")) > > (I'm not a reviewer. Oh you are correct. I?ll update the patch. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Mar 27 15:57:24 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 27 Mar 2017 08:57:24 -0700 Subject: JDK 9 RFR of 8177559: Enable java/nio/channels/Selector/OutOfBand.java for macOS >= 10.10.5 In-Reply-To: <691537cd-7312-3394-749a-a790307f5c74@oracle.com> References: <6BC3F62B-2AB4-4E7F-916C-995019C7EAA1@oracle.com> <691537cd-7312-3394-749a-a790307f5c74@oracle.com> Message-ID: <4F96414A-D952-4C65-9F87-A77A4B514976@oracle.com> On Mar 26, 2017, at 7:27 PM, Amy Lu wrote: > On 3/25/17 4:06 AM, Brian Burkhalter wrote: >> Please review this test-only change at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8177559 >> Patch: http://cr.openjdk.java.net/~bpb/8177559/webrev.00/ > > This makes test still run at 10.10 ... 10.10.4 > > How about : > > * @requires (os.family != "mac") > * | ((os.simpleVersion == "10.10") & (os.version == "10.10.5")) > * | ((os.simpleVersion != "10.10") & (os.simpleVersion != "10.9") & (os.simpleVersion != "10.8")) Here is an updated version slightly different from that suggested above: http://cr.openjdk.java.net/~bpb/8177559/webrev.01/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Tue Mar 28 05:49:45 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 28 Mar 2017 13:49:45 +0800 Subject: JDK 9 RFR of 8177559: Enable java/nio/channels/Selector/OutOfBand.java for macOS >= 10.10.5 In-Reply-To: <91E05DEA-7A6F-4579-8468-4B6676F60FAC@oracle.com> References: <6BC3F62B-2AB4-4E7F-916C-995019C7EAA1@oracle.com> <691537cd-7312-3394-749a-a790307f5c74@oracle.com> <91E05DEA-7A6F-4579-8468-4B6676F60FAC@oracle.com> Message-ID: <5886c798-8232-334b-9656-aa6b74b44266@oracle.com> On 3/27/17 11:36 PM, Brian Burkhalter wrote: > Hi Amy, > > On Mar 26, 2017, at 7:27 PM, Amy Lu > wrote: > >> On 3/25/17 4:06 AM, Brian Burkhalter wrote: >>> Please review this test-only change at your convenience. >>> >>> Issue:https://bugs.openjdk.java.net/browse/JDK-8177559 >>> Patch:http://cr.openjdk.java.net/~bpb/8177559/webrev.00/ >>> >> >> This makes test still run at 10.10 ? 10.10.4 > > Do you know whether it passes on any 10.x before 10.10.5? Sorry I don't know. The only 10.10.x machines I can find are 10.10.2 (test fail) and 10.10.5 (test pass). Thanks, Amy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Mar 28 13:51:30 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Mar 2017 14:51:30 +0100 Subject: JDK 9 RFR of 8177559: Enable java/nio/channels/Selector/OutOfBand.java for macOS >= 10.10.5 In-Reply-To: <4F96414A-D952-4C65-9F87-A77A4B514976@oracle.com> References: <6BC3F62B-2AB4-4E7F-916C-995019C7EAA1@oracle.com> <691537cd-7312-3394-749a-a790307f5c74@oracle.com> <4F96414A-D952-4C65-9F87-A77A4B514976@oracle.com> Message-ID: On 27/03/2017 16:57, Brian Burkhalter wrote: > > Here is an updated version slightly different from that suggested above: > > http://cr.openjdk.java.net/~bpb/8177559/webrev.01/ > > > This update looks okay although it might be simpler to leave 10.10.5 out (up to you). -Alan From brian.burkhalter at oracle.com Tue Mar 28 15:08:45 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 28 Mar 2017 08:08:45 -0700 Subject: JDK 9 RFR of 8177559: Enable java/nio/channels/Selector/OutOfBand.java for macOS >= 10.10.5 In-Reply-To: <5886c798-8232-334b-9656-aa6b74b44266@oracle.com> References: <6BC3F62B-2AB4-4E7F-916C-995019C7EAA1@oracle.com> <691537cd-7312-3394-749a-a790307f5c74@oracle.com> <91E05DEA-7A6F-4579-8468-4B6676F60FAC@oracle.com> <5886c798-8232-334b-9656-aa6b74b44266@oracle.com> Message-ID: <200495A8-8ED8-457A-9AA4-DF98E04CC1BB@oracle.com> Hi Amy, On Mar 27, 2017, at 10:49 PM, Amy Lu wrote: >> Do you know whether it passes on any 10.x before 10.10.5? > > Sorry I don't know. The only 10.10.x machines I can find are 10.10.2 (test fail) and 10.10.5 (test pass). So we?d best assume >= 10.10.5. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Mar 29 07:47:03 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Mar 2017 08:47:03 +0100 Subject: normalization changes in APFS In-Reply-To: References: Message-ID: <74837761-8f3a-8286-c1a8-a4b177114c1d@oracle.com> On 26/03/2017 11:44, Philippe Marschall wrote: > Hello > > In APFS, likely shipping with macOS 10.13, file names are not longer > stored in nfd [1]. The behaviour now seems very similar to Linux. That > means it's possible to have different two files names in the same > folder that normalize to the same name. > > AFAIK currently nfd->nfc conversion happens in the Java NIO file > system layer (JDK-7130915). It may make sense to revisit that. > > [1] http://mjtsai.com/blog/2017/03/24/apfss-bag-of-bytes-filenames/ > Thanks for the note on this. I read several articles about the changes in iOS 10.3 but if macOS also moves then the JDK will need to deal with it. -Alan From philippe.marschall at gmail.com Wed Mar 29 19:20:19 2017 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Wed, 29 Mar 2017 21:20:19 +0200 Subject: normalization changes in APFS In-Reply-To: <74837761-8f3a-8286-c1a8-a4b177114c1d@oracle.com> References: <74837761-8f3a-8286-c1a8-a4b177114c1d@oracle.com> Message-ID: On Wed, Mar 29, 2017 at 9:47 AM, Alan Bateman wrote: > On 26/03/2017 11:44, Philippe Marschall wrote: > .. > Thanks for the note on this. I read several articles about the changes in > iOS 10.3 but if macOS also moves then the JDK will need to deal with it. On macOS 10.12.4 I was able to create file named 0xC3, 0xA4 (? precomposed) and one named 0x61, 0xCC, 0x88 (? decomposed) in the same folder. So this seems to hold true. Interestingly I was not able to create a file named 0xE4 (invalid UTF-8) which was working on HFS+. [1] https://github.com/marschall/filename-fun/blob/master/filename-fun.c Cheers Philippe