From brian.burkhalter at oracle.com Thu Sep 3 17:39:14 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 3 Sep 2015 10:39:14 -0700 Subject: [PATCH] 8133647: (ch) Test java/nio/channels/AsynchronousSocketChannel/StressLoopback.java fails for Windows XP Message-ID: <4CCAA2BB-2E4A-44D8-93E3-D0C4930052C7@oracle.com> Please review at your convenience this patch for jdk8u-dev. Issue: https://bugs.openjdk.java.net/browse/JDK-8133647 Patch: included below Summary: Ignore WSAEINVAL returned from NET_EnableFastTcpLoopback(). With this patch the test now succeeds on Windows XP and the usual regression test target platforms. The change to StressLoopback.java is not very interesting: perhaps a ?noreg-trivial? label on the issue would be better? Subsequent to approval a separate request will be sent to jdk8u-dev. Thanks, Brian --- a/src/windows/native/sun/nio/ch/Net.c +++ b/src/windows/native/sun/nio/ch/Net.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -157,7 +157,7 @@ if (loopback_available) { int rv = NET_EnableFastTcpLoopback((jint)s); if (rv) { - if (rv == WSAEOPNOTSUPP) { + if (rv == WSAEOPNOTSUPP || rv == WSAEINVAL) { loopback_available = 0; } else { NET_ThrowNew(env, rv, "fastLoopback"); diff --git a/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java b/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java --- a/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java +++ b/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2008, 2009, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -22,7 +22,7 @@ */ /* @test - * @bug 6834246 6842687 + * @bug 6834246 6842687 8133647 * @summary Stress test connections through the loopback interface * @run main StressLoopback * @run main/othervm -Djdk.net.useFastTcpLoopback StressLoopback -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu Sep 3 17:57:07 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 3 Sep 2015 18:57:07 +0100 Subject: [PATCH] 8133647: (ch) Test java/nio/channels/AsynchronousSocketChannel/StressLoopback.java fails for Windows XP In-Reply-To: <4CCAA2BB-2E4A-44D8-93E3-D0C4930052C7@oracle.com> References: <4CCAA2BB-2E4A-44D8-93E3-D0C4930052C7@oracle.com> Message-ID: <55E889F3.7080602@oracle.com> Looks fine Brian. I made a similar change when porting this fix to jdk7. Since WinXP was not supported on JDK 8, I didn't see it as important. Probably still a good move to fix in jdk8u to keep windows XP breathing where possible I guess. Thanks for handling. Regards, Sean. On 03/09/2015 18:39, Brian Burkhalter wrote: > Please review at your convenience this patch for jdk8u-dev. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8133647 > Patch:included below > > Summary: > > Ignore WSAEINVAL returned from NET_EnableFastTcpLoopback(). With this > patch the test now succeeds on Windows XP and the usual regression > test target platforms. > > The change to StressLoopback.java is not very interesting: perhaps a > ?noreg-trivial? label on the issue would be better? > > Subsequent to approval a separate request will be sent to jdk8u-dev. > > Thanks, > > Brian > > --- a/src/windows/native/sun/nio/ch/Net.c > +++ b/src/windows/native/sun/nio/ch/Net.c > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -157,7 +157,7 @@ > if (loopback_available) { > int rv = NET_EnableFastTcpLoopback((jint)s); > if (rv) { > - if (rv == WSAEOPNOTSUPP) { > + if (rv == WSAEOPNOTSUPP || rv == WSAEINVAL) { > loopback_available = 0; > } else { > NET_ThrowNew(env, rv, "fastLoopback"); > diff --git > a/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java > b/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java > --- a/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java > +++ b/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2008, 2009, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -22,7 +22,7 @@ > */ > > > /* @test > - * @bug 6834246 6842687 > + * @bug 6834246 6842687 8133647 > * @summary Stress test connections through the loopback interface > * @run main StressLoopback > * @run main/othervm -Djdk.net.useFastTcpLoopback StressLoopback -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Sep 3 18:44:29 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Sep 2015 19:44:29 +0100 Subject: [PATCH] 8133647: (ch) Test java/nio/channels/AsynchronousSocketChannel/StressLoopback.java fails for Windows XP In-Reply-To: <4CCAA2BB-2E4A-44D8-93E3-D0C4930052C7@oracle.com> References: <4CCAA2BB-2E4A-44D8-93E3-D0C4930052C7@oracle.com> Message-ID: <55E8950D.7090107@oracle.com> On 03/09/2015 18:39, Brian Burkhalter wrote: > Please review at your convenience this patch for jdk8u-dev. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8133647 > Patch:included below > > This looks fine, it matches what was done for 7u too. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Sep 4 17:54:04 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 4 Sep 2015 10:54:04 -0700 Subject: [9-test-only] RFR of 8135091: (fs) java/nio/file/Files/StreamLinesTest.java should test empty files Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8135091 Webrev: http://cr.openjdk.java.net/~bpb/8135091/webrev.00/ Summary: In lines() add zero length case and rearrange first loop to avoid duplicate cases. Thanks, Brian From Roger.Riggs at Oracle.com Fri Sep 4 18:13:19 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 4 Sep 2015 14:13:19 -0400 Subject: [9-test-only] RFR of 8135091: (fs) java/nio/file/Files/StreamLinesTest.java should test empty files In-Reply-To: References: Message-ID: <55E9DF3F.5020905@Oracle.com> Hi Brian, Looks fine to me. Roger On 9/4/2015 1:54 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8135091 > Webrev: http://cr.openjdk.java.net/~bpb/8135091/webrev.00/ > > Summary: > In lines() add zero length case and rearrange first loop to avoid duplicate cases. > > Thanks, > > Brian From Alan.Bateman at oracle.com Sat Sep 5 14:11:41 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 05 Sep 2015 15:11:41 +0100 Subject: [9-test-only] RFR of 8135091: (fs) java/nio/file/Files/StreamLinesTest.java should test empty files In-Reply-To: References: Message-ID: <55EAF81D.1060407@oracle.com> On 04/09/2015 18:54, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8135091 > Webrev: http://cr.openjdk.java.net/~bpb/8135091/webrev.00/ > > Summary: > In lines() add zero length case and rearrange first loop to avoid duplicate cases. > > This looks okay to me. -Alan From andrewscully at gmail.com Tue Sep 8 08:43:14 2015 From: andrewscully at gmail.com (Andrew Scully) Date: Tue, 8 Sep 2015 09:43:14 +0100 Subject: NoSuchFileException thrown by FileTreeWalker Message-ID: Hi, The below exception was thrown on a CentOS 7.1 system running Oracle JDK 8u51 64-bit during a walk of a file directory: java.nio.file.NoSuchFileException: /home/reims/vcs-v70/VCS-SCS/reims/config/definition-import/cdr/OI-UpdateODRApplStatusByTransNo-1-0-0.xml.processed at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55) at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144) at sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99) at java.nio.file.Files.readAttributes(Files.java:1737) at java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:219) at java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276) at java.nio.file.FileTreeWalker.next(FileTreeWalker.java:372) at java.nio.file.Files.walkFileTree(Files.java:2706) at java.nio.file.Files.walkFileTree(Files.java:2742) at com.saaconsultants.osp.admin.svc.OspPersistenceServiceImpl$2.run(OspPersistenceServiceImpl.java:268) The directory in question was probably being modified at the time, so it's entirely possible that the file in question was deleted mid-walk. The JavaDoc for the method (https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#walkFileTree-java.nio.file.Path-java.nio.file.FileVisitor-) states that an IOException is only thrown "if an I/O error is thrown by a visitor method", but in this case it appears at least that the exception is being thrown by the walker implementation itself. The visitor in use is a java.nio.file.SimpleFileVisitor that overrides the #visitFile() and #preVisitDirectory() methods only. Any thoughts on how best to proceed (including a more appropriate mailing list if this isn't the right one!) would be greatly appreciated. Kind Regards, Andrew Scully. From Alan.Bateman at oracle.com Tue Sep 8 11:11:52 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Sep 2015 12:11:52 +0100 Subject: NoSuchFileException thrown by FileTreeWalker In-Reply-To: References: Message-ID: <55EEC278.8070803@oracle.com> On 08/09/2015 09:43, Andrew Scully wrote: > : > > The visitor in use is a java.nio.file.SimpleFileVisitor that overrides > the #visitFile() and #preVisitDirectory() methods only. > > Any thoughts on how best to proceed (including a more appropriate > mailing list if this isn't the right one!) would be greatly > appreciated. > There was a lot of discussion a few years ago on the various "strategies" for dealing with errors when doing recursive operations. Files.walkFileTree was intended to let the user of the API decide how they want to handle errors, be it ignore, log, collect, fail, fail after some threshold, etc. So it does depend on whether you want to handle the errors. If you do, then it means overriding the visitFile method. -Alan From brian.burkhalter at oracle.com Tue Sep 8 23:26:26 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 8 Sep 2015 16:26:26 -0700 Subject: JDK-8054039 Deadlock during interrupting FileChannel In-Reply-To: <012c01d0ea1b$74666ab0$5d334010$@oracle.com> References: <00fe01d08bd0$6314f280$293ed780$@oracle.com> <5550803B.50203@oracle.com> <24497227-B196-4F23-A84E-F51839F83D88@oracle.com> <00e201d098ef$2a7dfd50$7f79f7f0$@oracle.com> <01f501d0c51b$9b6d3a00$d247ae00$@oracle.com> <55B09C61.6000005@oracle.com> <012c01d0ea1b$74666ab0$5d334010$@oracle.com> Message-ID: <9E67E71D-4861-4B5C-868C-BDE0878E3533@oracle.com> Hi Frank, Sorry that this topic has languished for so long with no comment. On Sep 8, 2015, at 2:47 AM, Frank Yuan wrote: > Thread 1 and thread 2 invoke map() on a same FileChannel, at same time, thread 3 is interrupting thread 2, if it happens to meet the conditions at the 4 time points, thread 2 will hold closeLock of the FileChannel and try to get the blockerLock of itself(i.e. thread 2), thread 3 will hold blockerLock of thread 2 and try to get closeLock of the FileChannel, that will result in the dead lock. This analysis appears to me to be accurate. > With applying attached deadlock.diff, in which I add some delay code at some points, the dead lock happens very easy, refer to the attached <>, if you use agentvm mode, jtreg will even report the dead lock found, see <> > > I have 2 solutions to fix this issue. The first one is to be like the attached fix1.diff, if I understand correctly, in signalAndWait(), Thread.currentThread().interrupt() is just to set interrupted flag again, the whole interrupt() is unnecessary, in my fix1.diff, I invoke Thread. interrupt0() by reflection, this is not the final code, just an example. I am suspicious of the use of reflection here. > The second solution is << 8054039.diff >>, which has been attached inhttps://bugs.openjdk.java.net/secure/attachment/28435/8054039.diff. In this fix, I replace closeLock in AbstractInterruptibleChannel.java with AtomicBoolean and compareAndSet(), that eliminates one of the locks, like my solution 1. Within the scope of AbstractInterruptibleChannel I do not see any problem with the change that you propose. Given that the affected instance variables are private to the class and that AtomicBoolean ?generally? follows the rules for volatiles it looks conceptually valid. I do not know however about the implications with respect to interactions with other classes. For example, could this change provoke some unforeseen behavior as a result of subtle changes in timing? As for picky comments, the source file could use some minor cleanup in the form of removing unused imports and adding @Override annotations where appropriate. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.yuan at oracle.com Wed Sep 9 07:59:20 2015 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 9 Sep 2015 15:59:20 +0800 Subject: JDK-8054039 Deadlock during interrupting FileChannel In-Reply-To: <9E67E71D-4861-4B5C-868C-BDE0878E3533@oracle.com> References: <00fe01d08bd0$6314f280$293ed780$@oracle.com> <5550803B.50203@oracle.com> <24497227-B196-4F23-A84E-F51839F83D88@oracle.com> <00e201d098ef$2a7dfd50$7f79f7f0$@oracle.com> <01f501d0c51b$9b6d3a00$d247ae00$@oracle.com> <55B09C61.6000005@oracle.com> <012c01d0ea1b$74666ab0$5d334010$@oracle.com> <9E67E71D-4861-4B5C-868C-BDE0878E3533@oracle.com> Message-ID: <023401d0ead5$73d818e0$5b884aa0$@oracle.com> Hi Brian Thank you for review and your comments:) The size of my last mail is too large, is still held by maillist moderator, I have to send some content again(the diagram still can't be attached.). The bug is a dead lock may happen during a FileChannel is being interrupted. With applying attached <>, in which I add some delay code at some points, the dead lock happens very easy. I have 2 solutions to fix this issue. The first one is to be like the attached fix1.diff, if I understand correctly, in signalAndWait(), Thread.currentThread().interrupt() is just to set interrupted flag again, the whole interrupt() is unnecessary, in my <>, I invoke Thread. interrupt0() by reflection, this is not the final code, just an example. Brian's comment: I am suspicious of the use of reflection here. I also have some concern for this solution, because in this fix nio will depend on the private method of Thread -- interrupt0, it will break the encapsulation. However it's an available solution in theory. The second solution has been attached in https://bugs.openjdk.java.net/secure/attachment/28435/8054039.diff. In this fix, I replace closeLock in AbstractInterruptibleChannel.java with AtomicBoolean and compareAndSet(), that eliminates one of the locks, like my solution 1. Brian's comment: Within the scope of AbstractInterruptibleChannel I do not see any problem with the change that you propose. Given that the affected instance variables are private to the class and that AtomicBoolean "generally" follows the rules for volatiles it looks conceptually valid. I do not know however about the implications with respect to interactions with other classes. For example, could this change provoke some unforeseen behavior as a result of subtle changes in timing? As my understood, this solution won't spend more time on begin() than the old code, compareAndSet is atomic and there is no loop or wait. Anyway I am not sure your concern, will do more tests, hope more people can review it. Best Regards Frank From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Wednesday, September 09, 2015 7:26 AM To: Frank Yuan ; nio-dev Cc: FELIX YANG Subject: Re: JDK-8054039 Deadlock during interrupting FileChannel Hi Frank, Sorry that this topic has languished for so long with no comment. On Sep 8, 2015, at 2:47 AM, Frank Yuan > wrote: Thread 1 and thread 2 invoke map() on a same FileChannel, at same time, thread 3 is interrupting thread 2, if it happens to meet the conditions at the 4 time points, thread 2 will hold closeLock of the FileChannel and try to get the blockerLock of itself(i.e. thread 2), thread 3 will hold blockerLock of thread 2 and try to get closeLock of the FileChannel, that will result in the dead lock. This analysis appears to me to be accurate. With applying attached deadlock.diff, in which I add some delay code at some points, the dead lock happens very easy, refer to the attached <>, if you use agentvm mode, jtreg will even report the dead lock found, see <> I have 2 solutions to fix this issue. The first one is to be like the attached fix1.diff, if I understand correctly, in signalAndWait(), Thread.currentThread().interrupt() is just to set interrupted flag again, the whole interrupt() is unnecessary, in my fix1.diff, I invoke Thread. interrupt0() by reflection, this is not the final code, just an example. I am suspicious of the use of reflection here. The second solution is << 8054039.diff >>, which has been attached in https://bugs.openjdk.java.net/secure/attachment/28435/8054039.diff. In this fix, I replace closeLock in AbstractInterruptibleChannel.java with AtomicBoolean and compareAndSet(), that eliminates one of the locks, like my solution 1. Within the scope of AbstractInterruptibleChannel I do not see any problem with the change that you propose. Given that the affected instance variables are private to the class and that AtomicBoolean "generally" follows the rules for volatiles it looks conceptually valid. I do not know however about the implications with respect to interactions with other classes. For example, could this change provoke some unforeseen behavior as a result of subtle changes in timing? As for picky comments, the source file could use some minor cleanup in the form of removing unused imports and adding @Override annotations where appropriate. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fix1.diff Type: application/octet-stream Size: 832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: deadlock.diff Type: application/octet-stream Size: 2292 bytes Desc: not available URL: From brian.burkhalter at oracle.com Wed Sep 9 14:58:19 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Sep 2015 07:58:19 -0700 Subject: JDK-8054039 Deadlock during interrupting FileChannel In-Reply-To: <023401d0ead5$73d818e0$5b884aa0$@oracle.com> References: <00fe01d08bd0$6314f280$293ed780$@oracle.com> <5550803B.50203@oracle.com> <24497227-B196-4F23-A84E-F51839F83D88@oracle.com> <00e201d098ef$2a7dfd50$7f79f7f0$@oracle.com> <01f501d0c51b$9b6d3a00$d247ae00$@oracle.com> <55B09C61.6000005@oracle.com> <012c01d0ea1b$74666ab0$5d334010$@oracle.com> <9E67E71D-4861-4B5C-868C-BDE0878E3533@oracle.com> <023401d0ead5$73d818e0$5b884aa0$@oracle.com> Message-ID: <3C7C5557-378D-49A9-82FD-5032018C87C8@oracle.com> Hi Frank, On Sep 9, 2015, at 12:59 AM, Frank Yuan wrote: > Thank you for review and your comments:) You are welcome. > The size of my last mail is too large, is still held by maillist moderator, I have to send some content again(the diagram still can't be attached?). You could upload the diagram and a webrev to cr.openjdk.java.net assuming you have an ID. If not, I could do it for you. > I am suspicious of the use of reflection here. > I also have some concern for this solution, because in this fix nio will depend on the private method of Thread -- interrupt0, it will break the encapsulation. However it's an available solution in theory. True but I think the second one is better. > Within the scope of AbstractInterruptibleChannel I do not see any problem with the change that you propose. Given that the affected instance variables are private to the class and that AtomicBoolean ?generally? follows the rules for volatiles it looks conceptually valid. I do not know however about the implications with respect to interactions with other classes. For example, could this change provoke some unforeseen behavior as a result of subtle changes in timing? > > As my understood, this solution won't spend more time on begin() than the old code, compareAndSet is atomic and there is no loop or wait. Anyway I am not sure your concern, will do more tests, hope more people can review it. Indeed I don?t know whether there would be any effect: it was simply an observation. I expect others will comment when they have time. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcmuir at gmail.com Wed Sep 9 23:03:45 2015 From: rcmuir at gmail.com (Robert Muir) Date: Wed, 9 Sep 2015 19:03:45 -0400 Subject: AbstractInterruptibleChannel#close / tracking resource leaks Message-ID: Hello, In lucene we use the FileSystemProvider api to wrap the actual filesystem during test execution: * failing tests on resource leaks * failing tests if they use too many file handles * shuffling directory listing order in a predictable way * acting like windows for file deletions * adding optional low level logging We don't have problems but there is one ugly part, and that is delegation around FileChannel.close (because it is final). Our current solution is an ugly hack: https://github.com/apache/lucene-solr/blob/trunk/lucene/test-framework/src/java/org/apache/lucene/mockfile/FilterFileChannel.java#L139-L164 AsynchronousFileChannel does not have the issue, because its close() method isn't final, the problem is limited to just FileChannel. Is there a better way we can do this, or something that could be improved here? This evil technique (not surprisingly) fails with the jigsaw EA build, but it would be great to still be able to wrap the filesystem in tests to e.g. detect leaks and so on in the future. Thanks, Robert From brian.burkhalter at oracle.com Wed Sep 9 23:53:38 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Sep 2015 16:53:38 -0700 Subject: AbstractInterruptibleChannel#close / tracking resource leaks In-Reply-To: References: Message-ID: Hello Robert, Are the methods of the underlying FileChannel instance (?delegate?) ever accessed directly after it is used to create the FilterFileChannel? If not, why could you not simply do this: @Override protected void implCloseChannel() throws IOException { delegate.close(); } All AbstractInterruptibleChannel.close() does is to obtain an internal lock, check whether the channel is already closed, and if not call implCloseChannel(). If the underlying FileChannel is not accessed separately once the container is created it?s not immediately clear to me at least how there could be contention although I could easily be missing something. I do understand that this is not strict interposition which is what it looks like you are after. Regards, Brian On Sep 9, 2015, at 4:03 PM, Robert Muir wrote: > Is there a better way we can do this, or something that could be > improved here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcmuir at gmail.com Thu Sep 10 01:04:27 2015 From: rcmuir at gmail.com (Robert Muir) Date: Wed, 9 Sep 2015 21:04:27 -0400 Subject: AbstractInterruptibleChannel#close / tracking resource leaks In-Reply-To: References: Message-ID: Thank you very much: this works. You are right, I was very afraid because the two close methods have different semantics around them, so it seemed incorrect to do this... sorry for the noise. On Wed, Sep 9, 2015 at 7:53 PM, Brian Burkhalter wrote: > Hello Robert, > > Are the methods of the underlying FileChannel instance (?delegate?) ever > accessed directly after it is used to create the FilterFileChannel? If not, > why could you not simply do this: > > @Override > protected void implCloseChannel() throws IOException { > delegate.close(); > } > > All AbstractInterruptibleChannel.close() does is to obtain an internal lock, > check whether the channel is already closed, and if not call > implCloseChannel(). If the underlying FileChannel is not accessed separately > once the container is created it?s not immediately clear to me at least how > there could be contention although I could easily be missing something. I do > understand that this is not strict interposition which is what it looks like > you are after. > > Regards, > > Brian > > On Sep 9, 2015, at 4:03 PM, Robert Muir wrote: > > Is there a better way we can do this, or something that could be > improved here? > > From brian.burkhalter at oracle.com Thu Sep 10 01:07:05 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Sep 2015 18:07:05 -0700 Subject: AbstractInterruptibleChannel#close / tracking resource leaks In-Reply-To: References: Message-ID: <6CBE86CC-D2C3-41F4-AE55-5761862BD24B@oracle.com> No worries: the important thing is that it works. Brian On Sep 9, 2015, at 6:04 PM, Robert Muir wrote: > Thank you very much: this works. > > You are right, I was very afraid because the two close methods have > different semantics around them, so it seemed incorrect to do this... > sorry for the noise. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.yuan at oracle.com Thu Sep 10 09:04:18 2015 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 10 Sep 2015 17:04:18 +0800 Subject: JDK-8054039 Deadlock during interrupting FileChannel In-Reply-To: <3C7C5557-378D-49A9-82FD-5032018C87C8@oracle.com> References: <00fe01d08bd0$6314f280$293ed780$@oracle.com> <5550803B.50203@oracle.com> <24497227-B196-4F23-A84E-F51839F83D88@oracle.com> <00e201d098ef$2a7dfd50$7f79f7f0$@oracle.com> <01f501d0c51b$9b6d3a00$d247ae00$@oracle.com> <55B09C61.6000005@oracle.com> <012c01d0ea1b$74666ab0$5d334010$@oracle.com> <9E67E71D-4861-4B5C-868C-BDE0878E3533@oracle.com> <023401d0ead5$73d818e0$5b884aa0$@oracle.com> <3C7C5557-378D-49A9-82FD-5032018C87C8@oracle.com> Message-ID: <034301d0eba7$ae377440$0aa65cc0$@oracle.com> Hi Frank, On Sep 9, 2015, at 12:59 AM, Frank Yuan > wrote: Thank you for review and your comments:) You are welcome. The size of my last mail is too large, is still held by maillist moderator, I have to send some content again(the diagram still can't be attached.). You could upload the diagram and a webrev to cr.openjdk.java.net assuming you have an ID. If not, I could do it for you. I have uploaded the diagram to the bug https://bugs.openjdk.java.net/browse/JDK-8054039, hope more people can review it. I am suspicious of the use of reflection here. I also have some concern for this solution, because in this fix nio will depend on the private method of Thread -- interrupt0, it will break the encapsulation. However it's an available solution in theory. True but I think the second one is better. Within the scope of AbstractInterruptibleChannel I do not see any problem with the change that you propose. Given that the affected instance variables are private to the class and that AtomicBoolean "generally" follows the rules for volatiles it looks conceptually valid. I do not know however about the implications with respect to interactions with other classes. For example, could this change provoke some unforeseen behavior as a result of subtle changes in timing? As my understood, this solution won't spend more time on begin() than the old code, compareAndSet is atomic and there is no loop or wait. Anyway I am not sure your concern, will do more tests, hope more people can review it. Indeed I don't know whether there would be any effect: it was simply an observation. I expect others will comment when they have time. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Fri Sep 25 13:27:46 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 25 Sep 2015 16:27:46 +0300 Subject: [9] [XXS] RFR 8137121: (ch) Infinite loop in sun.nio.ch.FileChannelImpl.truncate Message-ID: <56054BD2.7070902@oracle.com> Hello! A long result of a call to position0 is blindly cast to int, which may accidentally result in (-3) special value. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8137121 WEBREV: http://cr.openjdk.java.net/~igerasim/8137121/00/webrev/ Sincerely yours, Ivan From Alan.Bateman at oracle.com Fri Sep 25 13:46:55 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Sep 2015 14:46:55 +0100 Subject: [9] [XXS] RFR 8137121: (ch) Infinite loop in sun.nio.ch.FileChannelImpl.truncate In-Reply-To: <56054BD2.7070902@oracle.com> References: <56054BD2.7070902@oracle.com> Message-ID: <5605504F.7060502@oracle.com> On 25/09/2015 14:27, Ivan Gerasimov wrote: > Hello! > > A long result of a call to position0 is blindly cast to int, which may > accidentally result in (-3) special value. > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8137121 > WEBREV: http://cr.openjdk.java.net/~igerasim/8137121/00/webrev/ The fix looks okay. I guess I would use rp rather than rl. Can you move the test into FileChannel directory? LoopingTruncate might be a a better name for the test. A minor comment is this might fit better on L51: try (FileChannel fc = FileChannel.open(path, CREATE, WRITE)) { -Alan From ivan.gerasimov at oracle.com Fri Sep 25 17:00:36 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 25 Sep 2015 20:00:36 +0300 Subject: [9] [XXS] RFR 8137121: (ch) Infinite loop in sun.nio.ch.FileChannelImpl.truncate In-Reply-To: <5605504F.7060502@oracle.com> References: <56054BD2.7070902@oracle.com> <5605504F.7060502@oracle.com> Message-ID: <56057DB4.60000@oracle.com> Thank you Alan! I'll incorporate all your suggestions before pushing the fix. Sincerely yours, Ivan On 25.09.2015 16:46, Alan Bateman wrote: > On 25/09/2015 14:27, Ivan Gerasimov wrote: >> Hello! >> >> A long result of a call to position0 is blindly cast to int, which >> may accidentally result in (-3) special value. >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8137121 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8137121/00/webrev/ > The fix looks okay. I guess I would use rp rather than rl. > > Can you move the test into FileChannel directory? LoopingTruncate > might be a a better name for the test. > > A minor comment is this might fit better on L51: > > try (FileChannel fc = FileChannel.open(path, CREATE, WRITE)) { > > -Alan > From ivan.gerasimov at oracle.com Mon Sep 28 17:19:13 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 28 Sep 2015 20:19:13 +0300 Subject: [9] [XXS] RFR 8137230: TEST_BUG: java/nio/channels/FileChannel/LoopingTruncate.java timed out Message-ID: <56097691.1000505@oracle.com> Hello! The just added test started to intermittently fail on some machines. It appears that creating a temporary file and doing some simple IO with it can sometimes take more than 10 seconds even without an infinite loop. The proposal is: - increase the timeout; - limit the amount of work to only truncation of the file; - if a case of failure, print a stacktrace of the frozen thread for a better diagnostic. With this change, the test passed on all the platforms. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8137230 WEBREV: http://cr.openjdk.java.net/~igerasim/8137230/00/webrev/ Sincerely yours, Ivan From Roger.Riggs at Oracle.com Mon Sep 28 17:59:46 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 28 Sep 2015 13:59:46 -0400 Subject: [9] [XXS] RFR 8137230: TEST_BUG: java/nio/channels/FileChannel/LoopingTruncate.java timed out In-Reply-To: <56097691.1000505@oracle.com> References: <56097691.1000505@oracle.com> Message-ID: <56098012.2020909@Oracle.com> Hi Ivan, Looks ok. One comment about timeouts, the test library has a function to extend the timeout based on the -timeoutOption; Using jdk.testlibrary.Utils.adjustTime(nn) is useful if the extension of the timeout will be useful depending on the execution machine or vm parameters. Roger On 9/28/2015 1:19 PM, Ivan Gerasimov wrote: > Hello! > > The just added test started to intermittently fail on some machines. > It appears that creating a temporary file and doing some simple IO > with it can sometimes take more than 10 seconds even without an > infinite loop. > > The proposal is: > - increase the timeout; > - limit the amount of work to only truncation of the file; > - if a case of failure, print a stacktrace of the frozen thread for a > better diagnostic. > > With this change, the test passed on all the platforms. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8137230 > WEBREV: http://cr.openjdk.java.net/~igerasim/8137230/00/webrev/ > > > Sincerely yours, > Ivan > From ivan.gerasimov at oracle.com Mon Sep 28 20:01:53 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 28 Sep 2015 23:01:53 +0300 Subject: [9] [XXS] RFR 8137230: TEST_BUG: java/nio/channels/FileChannel/LoopingTruncate.java timed out In-Reply-To: <56098012.2020909@Oracle.com> References: <56097691.1000505@oracle.com> <56098012.2020909@Oracle.com> Message-ID: <56099CB1.5070609@oracle.com> Thanks Roger! On 28.09.2015 20:59, Roger Riggs wrote: > Hi Ivan, > > Looks ok. > > One comment about timeouts, the test library has a function to extend > the timeout based > on the -timeoutOption; Using jdk.testlibrary.Utils.adjustTime(nn) is > useful if the extension > of the timeout will be useful depending on the execution machine or vm > parameters. > Yes, it'll be even safer with adjustTime(), thanks for suggesting. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8137230/01/webrev/ Sincerely yours, Ivan > Roger > > > On 9/28/2015 1:19 PM, Ivan Gerasimov wrote: >> Hello! >> >> The just added test started to intermittently fail on some machines. >> It appears that creating a temporary file and doing some simple IO >> with it can sometimes take more than 10 seconds even without an >> infinite loop. >> >> The proposal is: >> - increase the timeout; >> - limit the amount of work to only truncation of the file; >> - if a case of failure, print a stacktrace of the frozen thread for a >> better diagnostic. >> >> With this change, the test passed on all the platforms. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8137230 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8137230/00/webrev/ >> >> >> Sincerely yours, >> Ivan >> > >