From joe.darcy at oracle.com Thu May 1 00:20:16 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Apr 2014 17:20:16 -0700 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> <535633C2.5090501@gmail.com> <5356650F.5020909@redhat.com> <53568254.3010106@gmail.com> <535689DC.6060907@redhat.com> Message-ID: <53619340.6010505@oracle.com> Hello, I'm reminded of Professor Knuth's observation that "Premature optimization is the root of all evil." If from an API perspective the new code is preferable, I would say that should take precedence over an at most marginal performance degradation. If performance of is a high concern in that area, perhaps a jmh experiment could help tease about the difference in speed. -Joe On 04/27/2014 04:08 PM, Richard Warburton wrote: > Hi, > > There are multiple possible targets for invokevirtual >>> position:(I)Ljava/nio/Buffer; - all the methods that override it in all >>> subclasses loaded. It doesn't matter if they are final or not (only if >>> they are effectively final or not). The non-finality of a method has a >>> performance impact only if the method *is* overridden in any of the >>> loaded subclasses, otherwise it is effectively final and treated as such >>> by JIT (at least that's how I understand it - any hotspot JIT expert >>> please debunk my claims). >>> >> That is only true if you are calling the method on the base class, which >> is normally seldom done (though it will be nearly always in legacy code, >> but see below). >> >> That might also be the answer to why the synthetic method need not be >>> marked as final if the covariant method is. The synthetic method can >>> never be overridden in a sub-class (at least not by javac) - only the >>> covariant method can be. >>> >> Doesn't sound quite right to me, but I'll defer to any experts who might >> wish to discuss it on compiler-dev. >> >> >> But as Paul noted, the methods on Buffer are probably not used in hot >>> loops alone, since they are just for reading/adjusting >>> position/limit/mark. The hot loops probably also contain methods for >>> reading/writing the buffer and those are only defined on particular >>> sub-types of java.nio.Buffer, so it can reasonably be expected that the >>> static (guaranteed) type of target upon which methods are called in hot >>> loops is a particular subtype of java.nio.Buffer and JIT only has one >>> method to choose from in this case. >>> >> Yeah new code will call the covariant final method directly in almost all >> cases for sure, having been compiled against it. The tricky case is old >> code - even if the JIT can figure out that it is really a subclass being >> invoked upon, it'd still be forced to target the non-covariant synthetic >> method due to the specific method reference in the bytecode. Hopefully at >> this point though, as you say, the lack of overriding classes will be >> enough to optimize the dispatch. >> > So interestingly the original patch didn't add final to the covariant > overrides. I've updated the patch to do this. > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-1/ > > I'm not sure what would satisfy people on the performance front. Some > guidance would be most appreciated here. > > regards, > > Richard Warburton > > http://insightfullogic.com > @RichardWarburto From zhong.j.yu at gmail.com Thu May 1 00:50:14 2014 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Wed, 30 Apr 2014 19:50:14 -0500 Subject: 8041772: (ch) PendingFuture.CANCELLED has backtrace that potentially keeps objects alive In-Reply-To: <53614230.2030207@redhat.com> References: <535FA15F.1000609@oracle.com> <5360A63B.7050201@oracle.com> <53614230.2030207@redhat.com> Message-ID: On Wed, Apr 30, 2014 at 1:34 PM, Florian Weimer wrote: > On 04/30/2014 09:28 AM, Alan Bateman wrote: >> >> On 29/04/2014 22:47, Zhong Yu wrote: >>> >>> This would change the stacktrace the application sees; does it matter? >>> >> It's a good question and could be confusing to have get throw >> CancellationException with the stack trace of the thread that called >> cancel. So I think we'll leave this as it was. > > > Would it make sense to call setStackTrace(new StackTraceElement[0]) on the It doesn't clear `Throwable.backtrace` (should it though?) so it won't solve the problem. Calling constructor Throwable(x,x,x, writableStackTrace=false) seems working. > marker exception? The class retention issue looks it could cause problems > in some cases. > > -- > Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Fri May 2 12:14:57 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 02 May 2014 13:14:57 +0100 Subject: 8041772: (ch) PendingFuture.CANCELLED has backtrace that potentially keeps objects alive In-Reply-To: References: <535FA15F.1000609@oracle.com> <5360A63B.7050201@oracle.com> <53614230.2030207@redhat.com> Message-ID: <53638C41.7080303@oracle.com> On 01/05/2014 01:50, Zhong Yu wrote: > : > It doesn't clear `Throwable.backtrace` (should it though?) so it won't > solve the problem. > > Calling constructor Throwable(x,x,x, writableStackTrace=false) seems working. > > That's a protected constructor. In any case, I'm not sure that it's worth doing anything here. Cancellation and I/O are just not good bedfellows so I don't expect that it will be used very much. Also in normal usage then the Future will likely be in unreferenced quickly. If there are good examples where this might be a real issue then we can of course look at this again but I think that dropping the static field (as has been done) is the most important thing (and I'm happy you found that). -Alan From fweimer at redhat.com Fri May 2 14:24:36 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 02 May 2014 16:24:36 +0200 Subject: 8041772: (ch) PendingFuture.CANCELLED has backtrace that potentially keeps objects alive In-Reply-To: <53638C41.7080303@oracle.com> References: <535FA15F.1000609@oracle.com> <5360A63B.7050201@oracle.com> <53614230.2030207@redhat.com> <53638C41.7080303@oracle.com> Message-ID: <5363AAA4.8040405@redhat.com> On 05/02/2014 02:14 PM, Alan Bateman wrote: > That's a protected constructor. In any case, I'm not sure that it's > worth doing anything here. Cancellation and I/O are just not good > bedfellows so I don't expect that it will be used very much. Also in > normal usage then the Future will likely be in unreferenced quickly. If > there are good examples where this might be a real issue then we can of > course look at this again but I think that dropping the static field (as > has been done) is the most important thing (and I'm happy you found that). Oh, I assumed that it was necessary to keep the == check to avoid catching unrelated CancellationExceptions. If that's not the case, 9ea90ce2b8d9 looks okay. -- Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Tue May 6 14:38:26 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 May 2014 15:38:26 +0100 Subject: RFR [8011537]: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException In-Reply-To: <5368EA08.9020705@oracle.com> References: <5368EA08.9020705@oracle.com> Message-ID: <5368F3E2.7090802@oracle.com> On 06/05/2014 14:56, Ivan Gerasimov wrote: > Hello! > > The interrupted status of a thread gets cleared with a call to > Path.register(). > This is due to call to Object.wait(). > > Below is the fix with an updated regtest. > Would you please help review it? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8011537 > WEBREV: http://cr.openjdk.java.net/~igerasim/8011537/0/webrev/ The change looks good, an oversight in the original implementation. A minor comment on the test is that we can using try-with-resources (as WatchService is Closeable). The register could also use the varargs variant to avoid creating the array explicitly but either way is fine. -Alan From ivan.gerasimov at oracle.com Tue May 6 14:52:08 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 06 May 2014 18:52:08 +0400 Subject: RFR [8011537]: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException In-Reply-To: <5368F3E2.7090802@oracle.com> References: <5368EA08.9020705@oracle.com> <5368F3E2.7090802@oracle.com> Message-ID: <5368F718.8050405@oracle.com> Thank you Alan! >> >> The interrupted status of a thread gets cleared with a call to >> Path.register(). >> This is due to call to Object.wait(). >> >> Below is the fix with an updated regtest. >> Would you please help review it? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8011537 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8011537/0/webrev/ > The change looks good, an oversight in the original implementation. > > A minor comment on the test is that we can using try-with-resources > (as WatchService is Closeable). The register could also use the > varargs variant to avoid creating the array explicitly but either way > is fine. > I tried to make the added test consistent with the rest of the code. I can surely rewrite it, but should I refactor other code as well then? Sincerely yours, Ivan From Alan.Bateman at oracle.com Tue May 6 15:02:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 May 2014 16:02:09 +0100 Subject: RFR [8011537]: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException In-Reply-To: <5368F718.8050405@oracle.com> References: <5368EA08.9020705@oracle.com> <5368F3E2.7090802@oracle.com> <5368F718.8050405@oracle.com> Message-ID: <5368F971.40906@oracle.com> On 06/05/2014 15:52, Ivan Gerasimov wrote: > I tried to make the added test consistent with the rest of the code. > I can surely rewrite it, but should I refactor other code as well then? I think the the existing tests pre-date the vararg variant of register, there isn't a big need to change those. For the new test then it would be good to use try-with-resources here. It would be good to change testExceptions too but not important for this change. -Alan. From ivan.gerasimov at oracle.com Tue May 6 19:17:10 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 06 May 2014 23:17:10 +0400 Subject: RFR [8011537]: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException In-Reply-To: <5368F971.40906@oracle.com> References: <5368EA08.9020705@oracle.com> <5368F3E2.7090802@oracle.com> <5368F718.8050405@oracle.com> <5368F971.40906@oracle.com> Message-ID: <53693536.8070505@oracle.com> Thank you Alan! On 06.05.2014 19:02, Alan Bateman wrote: > On 06/05/2014 15:52, Ivan Gerasimov wrote: >> I tried to make the added test consistent with the rest of the code. >> I can surely rewrite it, but should I refactor other code as well then? > I think the the existing tests pre-date the vararg variant of > register, there isn't a big need to change those. > > For the new test then it would be good to use try-with-resources here. > Okay, changed it. > It would be good to change testExceptions too but not important for > this change. > I think it can be changed with the upcoming fix for 8042470, which will include modifications to this test anyways. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8011537/1/webrev/ Sincerely yours, Ivan From ivan.gerasimov at oracle.com Wed May 7 10:51:13 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 07 May 2014 14:51:13 +0400 Subject: RFR [8042470]: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified Message-ID: <536A1021.3020309@oracle.com> Hello! Browsing the code, I spotted a small glitch in the way Path.register processes its argument list. - it ignores OVERFLOW, if any were given. - it throws IAE, if no events were specified (excluding the ignored OVERFLOW). This way of processing would break, if OVERFLOW were the only kind of event given, but were specified more than once. Would you please help review the fix for this? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8042470 WEBREV: http://cr.openjdk.java.net/~igerasim/8042470/0/webrev/ Some minor code cleanup was also included in the change. In particular, the following line was added (seemed to be missing for some reason): 322 throw new RuntimeException("UnsupportedOperationException not thrown"); Sincerely yours, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed May 7 11:16:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 May 2014 12:16:40 +0100 Subject: RFR [8042470]: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified In-Reply-To: <536A1021.3020309@oracle.com> References: <536A1021.3020309@oracle.com> Message-ID: <536A1618.6020706@oracle.com> On 07/05/2014 11:51, Ivan Gerasimov wrote: > Hello! > > Browsing the code, I spotted a small glitch in the way Path.register > processes its argument list. > - it ignores OVERFLOW, if any were given. > - it throws IAE, if no events were specified (excluding the ignored > OVERFLOW). > > This way of processing would break, if OVERFLOW were the only kind of > event given, but were specified more than once. > > Would you please help review the fix for this? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8042470 > WEBREV: http://cr.openjdk.java.net/~igerasim/8042470/0/webrev/ > > Some minor code cleanup was also included in the change. > In particular, the following line was added (seemed to be missing for > some reason): > 322 throw new RuntimeException("UnsupportedOperationException not thrown"); > This looks good. Thanks for adding the missing throw of UOE, that was cleared missed in the original test. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed May 7 11:28:42 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 07 May 2014 12:28:42 +0100 Subject: RFR [8042470]: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified In-Reply-To: <536A1618.6020706@oracle.com> References: <536A1021.3020309@oracle.com> <536A1618.6020706@oracle.com> Message-ID: <536A18EA.9060105@oracle.com> On 07/05/14 12:16, Alan Bateman wrote: > On 07/05/2014 11:51, Ivan Gerasimov wrote: >> Hello! >> >> Browsing the code, I spotted a small glitch in the way Path.register >> processes its argument list. >> - it ignores OVERFLOW, if any were given. >> - it throws IAE, if no events were specified (excluding the ignored >> OVERFLOW). >> >> This way of processing would break, if OVERFLOW were the only kind of >> event given, but were specified more than once. >> >> Would you please help review the fix for this? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8042470 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8042470/0/webrev/ >> >> Some minor code cleanup was also included in the change. >> In particular, the following line was added (seemed to be missing for >> some reason): >> 322 throw new RuntimeException("UnsupportedOperationException not thrown"); >> > This looks good. Thanks for adding the missing throw of UOE, that was > cleared missed in the original test. The change looks good to me too. -Chris. > > -Alan. From Alan.Bateman at oracle.com Thu May 8 18:41:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 08 May 2014 19:41:48 +0100 Subject: RFR [8042470]: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified In-Reply-To: <536A1618.6020706@oracle.com> References: <536A1021.3020309@oracle.com> <536A1618.6020706@oracle.com> Message-ID: <536BCFEC.2010508@oracle.com> Ivan, I forgot one thing, the AbstractPoller is only used by the native implementations. There is a completely separate PollingWatchService for use on platforms where we don't hook into the native facility, that will need to be updated separately. -Alan. From Alan.Bateman at oracle.com Fri May 9 08:15:21 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 May 2014 09:15:21 +0100 Subject: RFR [8042470]: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified In-Reply-To: <536BCFEC.2010508@oracle.com> References: <536A1021.3020309@oracle.com> <536A1618.6020706@oracle.com> <536BCFEC.2010508@oracle.com> Message-ID: <536C8E99.9070101@oracle.com> I see Ivan has pushed this one already. I've created JDK-8042816 to fix up the PollingWatchService as otherwise the updated tests will fail on those platforms where we don't have a native implementation. The addition to Ivan's change is here: http://cr.openjdk.java.net/~alanb/8042816/webrev/ Thanks, Alan. From Alan.Bateman at oracle.com Fri May 9 08:26:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 May 2014 09:26:40 +0100 Subject: epollWait blocks ,but why consume cpu In-Reply-To: References: Message-ID: <536C9140.60602@oracle.com> On 09/05/2014 08:28, fuyou wrote: > I use the NetBeans profiler ,the result in attach. > > Which JDK build is this? I don't think we've had any reports of Selector spinning issues in some time. -Alan. From chris.hegarty at oracle.com Fri May 9 08:46:49 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 09 May 2014 09:46:49 +0100 Subject: RFR [8042470]: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified In-Reply-To: <536C8E99.9070101@oracle.com> References: <536A1021.3020309@oracle.com> <536A1618.6020706@oracle.com> <536BCFEC.2010508@oracle.com> <536C8E99.9070101@oracle.com> Message-ID: <536C95F9.50303@oracle.com> Looks good to me Alan. -Chris. On 09/05/14 09:15, Alan Bateman wrote: > > I see Ivan has pushed this one already. I've created JDK-8042816 to fix > up the PollingWatchService as otherwise the updated tests will fail on > those platforms where we don't have a native implementation. The > addition to Ivan's change is here: > > http://cr.openjdk.java.net/~alanb/8042816/webrev/ > > Thanks, > Alan. From ivan.gerasimov at oracle.com Fri May 9 09:16:58 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 09 May 2014 13:16:58 +0400 Subject: RFR [8042470]: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified In-Reply-To: <536C8E99.9070101@oracle.com> References: <536A1021.3020309@oracle.com> <536A1618.6020706@oracle.com> <536BCFEC.2010508@oracle.com> <536C8E99.9070101@oracle.com> Message-ID: <536C9D0A.7050102@oracle.com> Oops. I should have run the test on all the platforms, not only on Linux. Sorry about that. Sincerely yours, Ivan On 09.05.2014 12:15, Alan Bateman wrote: > > I see Ivan has pushed this one already. I've created JDK-8042816 to > fix up the PollingWatchService as otherwise the updated tests will > fail on those platforms where we don't have a native implementation. > The addition to Ivan's change is here: > > http://cr.openjdk.java.net/~alanb/8042816/webrev/ > > Thanks, > Alan. > > From jeremymanson at google.com Sat May 10 04:44:56 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 9 May 2014 21:44:56 -0700 Subject: epollWait blocks ,but why consume cpu In-Reply-To: <536C9140.60602@oracle.com> References: <536C9140.60602@oracle.com> Message-ID: Are you sure it consumes CPU? I've always found that epollwait blocks, but the JVM doesn't know it is supposed to change the state of the thread. This is one of the major reasons that thread dump based profilers are awful. Jeremy On Fri, May 9, 2014 at 1:26 AM, Alan Bateman wrote: > On 09/05/2014 08:28, fuyou wrote: > >> I use the NetBeans profiler ,the result in attach. >> >> >> Which JDK build is this? I don't think we've had any reports of Selector > spinning issues in some time. > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luchsh at linux.vnet.ibm.com Mon May 26 09:04:38 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 26 May 2014 17:04:38 +0800 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX Message-ID: Hello, May I have following patch reviewed ? http://cr.openjdk.java.net/~luchsh/JDK-8043495/ The patch will add native FileChannelImpl.transferTo0() implementation for AIX by using the 'send_file' API, http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/send_file.htm?lang=en Thanks Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon May 26 10:09:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 May 2014 11:09:53 +0100 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: References: Message-ID: <538312F1.10503@oracle.com> On 26/05/2014 10:04, Jonathan Lu wrote: > Hello, > > May I have following patch reviewed ? > > http://cr.openjdk.java.net/~luchsh/JDK-8043495/ > > > The patch will add native FileChannelImpl.transferTo0() implementation > for AIX > by using the 'send_file' API, > http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/send_file.htm?lang=en Is the getsockopt needed to test the destination? I don't have access to a system with AIX and the man page you cite seems to detect this and give you the ENOTSOCK. Otherwise I don't see any issues with this, a minor consistent issue at L245 where it could be "< 0". Just looking at the OSX implementation just before this in the function and there is redundant ifdef __APPLE__. We could fix it with this patch or use another bug, I don't of course want to expand the scope of your change. -Alan From luchsh at linux.vnet.ibm.com Tue May 27 06:31:49 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 27 May 2014 14:31:49 +0800 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: <538312F1.10503@oracle.com> References: <538312F1.10503@oracle.com> Message-ID: Hi Alan, Thank you for the comments, here's the updated webrev, http://cr.openjdk.java.net/~luchsh/JDK-8043495-2/ On Mon, May 26, 2014 at 6:09 PM, Alan Bateman wrote: > On 26/05/2014 10:04, Jonathan Lu wrote: > >> Hello, >> >> May I have following patch reviewed ? >> >> http://cr.openjdk.java.net/~luchsh/JDK-8043495/ < >> http://cr.openjdk.java.net/%7Eluchsh/JDK-8043495/> >> >> >> The patch will add native FileChannelImpl.transferTo0() implementation >> for AIX >> by using the 'send_file' API, >> http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/ >> com.ibm.aix.commtrf2/send_file.htm?lang=en >> > Is the getsockopt needed to test the destination? I don't have access to a > system with AIX and the man page you cite seems to detect this and give you > the ENOTSOCK. > Agree, the updated patch has removed getsockopt and will check ENOTSOCK if send_file() reports error (-1). > > Otherwise I don't see any issues with this, a minor consistent issue at > L245 where it could be "< 0". > Fixed in the updated patch. > > Just looking at the OSX implementation just before this in the function > and there is redundant ifdef __APPLE__. We could fix it with this patch or > use another bug, I don't of course want to expand the scope of your change. > I'm OK with this minor removal and have done that in the second patch, please review. > > -Alan > > > Thanks Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue May 27 06:49:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 07:49:27 +0100 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: References: <538312F1.10503@oracle.com> Message-ID: <53843577.8050709@oracle.com> On 27/05/2014 07:31, Jonathan Lu wrote: > Hi Alan, > > Thank you for the comments, here's the updated webrev, > http://cr.openjdk.java.net/~luchsh/JDK-8043495-2/ > Thanks for the updates and for including the the ifdef __APPLE__ change. With the getsockopt removed then maybe socket.h is not needed now? Otherwise looks good to me. -Alan. From volker.simonis at gmail.com Tue May 27 08:49:46 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 May 2014 10:49:46 +0200 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: <53843577.8050709@oracle.com> References: <538312F1.10503@oracle.com> <53843577.8050709@oracle.com> Message-ID: On Tue, May 27, 2014 at 8:49 AM, Alan Bateman wrote: > On 27/05/2014 07:31, Jonathan Lu wrote: >> >> Hi Alan, >> >> Thank you for the comments, here's the updated webrev, >> http://cr.openjdk.java.net/~luchsh/JDK-8043495-2/ >> > > Thanks for the updates and for including the the ifdef __APPLE__ change. > With the getsockopt removed then maybe socket.h is not needed now? Otherwise > looks good to me. 'send_file()' is declared in 'sys/socket.h' on AIX, so we need it. The change looks good to me as well. Thanks for contributing it! Is there any test which exercises this code? Regards, Volker > > -Alan. From Alan.Bateman at oracle.com Tue May 27 09:00:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 10:00:08 +0100 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: References: <538312F1.10503@oracle.com> <53843577.8050709@oracle.com> Message-ID: <53845418.606@oracle.com> On 27/05/2014 09:49, Volker Simonis wrote: > : > 'send_file()' is declared in 'sys/socket.h' on AIX, so we need it. Thanks, just checking. > : > > > Is there any test which exercises this code? > The tests in java/nio/channels/FileChannel are the tests to run, they will give the transfer methods a good work out. -Alan. From chuanshenglu at gmail.com Tue May 27 09:43:37 2014 From: chuanshenglu at gmail.com (Jonathan Lu) Date: Tue, 27 May 2014 17:43:37 +0800 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: <53845418.606@oracle.com> References: <538312F1.10503@oracle.com> <53843577.8050709@oracle.com> <53845418.606@oracle.com> Message-ID: Thanks, Alan and Volker! I will push this change. Regards, Jonathan On Tue, May 27, 2014 at 5:00 PM, Alan Bateman wrote: > On 27/05/2014 09:49, Volker Simonis wrote: > >> : >> 'send_file()' is declared in 'sys/socket.h' on AIX, so we need it. >> > Thanks, just checking. > > > : >> >> >> Is there any test which exercises this code? >> >> The tests in java/nio/channels/FileChannel are the tests to run, they > will give the transfer methods a good work out. > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue May 27 09:56:31 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 27 May 2014 10:56:31 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: References: Message-ID: Looks good to me Pavel. I can sponsor this change for you. -Chris. On 27 May 2014, at 10:40, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8024832? > > http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ > > Thanks > -Pavel From michael.x.mcmahon at oracle.com Tue May 27 10:01:12 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 27 May 2014 11:01:12 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: References: Message-ID: <53846268.8080703@oracle.com> I think it should be throwing a SocketException rather than a NotYetBoundException to be consistent with ServerSocket.accept() Michael. On 27/05/14 10:56, Chris Hegarty wrote: > Looks good to me Pavel. I can sponsor this change for you. > > -Chris. > > On 27 May 2014, at 10:40, Pavel Rappo wrote: > >> Hi everyone, >> >> Could you please review my change for JDK-8024832? >> >> http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ >> >> Thanks >> -Pavel From Alan.Bateman at oracle.com Tue May 27 10:03:23 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 11:03:23 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: References: Message-ID: <538462EB.2050205@oracle.com> On 27/05/2014 10:40, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8024832? > > http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ > Can you try just removing the isBound check? I ask because ssc.accept() will throw NotYetBoundException if the ServerSocketChannel is not bound and that should get mapped to the SocketException to match ServerSocket behavior. -Alan. From pavel.rappo at oracle.com Tue May 27 10:19:45 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 27 May 2014 11:19:45 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <538462EB.2050205@oracle.com> References: <538462EB.2050205@oracle.com> Message-ID: <15048D49-1D85-486B-B925-D784A342E03F@oracle.com> Alan, I don't think it would be exactly the same behaviour since there's a conditional check (1) before the ssc.accept call: try { if (!ssc.isBound()) throw new NotYetBoundException(); (1) if (timeout == 0) { SocketChannel sc = ssc.accept(); if (sc == null && !ssc.isBlocking()) throw new IllegalBlockingModeException(); return sc.socket(); } (2) ssc.configureBlocking(false); try { SocketChannel sc; (3) if ((sc = ssc.accept()) != null) So if I remove this explicit check, than depending on condition (1) it can be the case that (3) will be executed after (2). And (2) can throw a bunch of different exceptions, hiding the otherwise initial NotYetBoundException. If it's not a concern I'm happy to remove this check. -Pavel On 27 May 2014, at 11:03, Alan Bateman wrote: > On 27/05/2014 10:40, Pavel Rappo wrote: >> Hi everyone, >> >> Could you please review my change for JDK-8024832? >> >> http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ >> > Can you try just removing the isBound check? I ask because ssc.accept() will throw NotYetBoundException if the ServerSocketChannel is not bound and that should get mapped to the SocketException to match ServerSocket behavior. > > -Alan. From Alan.Bateman at oracle.com Tue May 27 13:12:41 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 14:12:41 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <15048D49-1D85-486B-B925-D784A342E03F@oracle.com> References: <538462EB.2050205@oracle.com> <15048D49-1D85-486B-B925-D784A342E03F@oracle.com> Message-ID: <53848F49.7050809@oracle.com> On 27/05/2014 11:19, Pavel Rappo wrote: > Alan, > > I don't think it would be exactly the same behaviour since there's a conditional check (1) before the ssc.accept call: > > try { > if (!ssc.isBound()) > throw new NotYetBoundException(); > (1) if (timeout == 0) { > SocketChannel sc = ssc.accept(); > if (sc == null && !ssc.isBlocking()) > throw new IllegalBlockingModeException(); > return sc.socket(); > } > > (2) ssc.configureBlocking(false); > try { > SocketChannel sc; > (3) if ((sc = ssc.accept()) != null) > > So if I remove this explicit check, than depending on condition (1) it can be the case that (3) will be executed after (2). And (2) can throw a bunch of different exceptions, hiding the otherwise initial NotYetBoundException. > > If it's not a concern I'm happy to remove this check. > For the no-timeout case then it would be the same. For the timeout case it it just means that the channel might be changed to non-blocking before the exception is thrown. I don't think this is a problem as it will be restored anyway. What you have is fine, I think just removing is fine too. -Alan. From michael.x.mcmahon at oracle.com Tue May 27 15:10:12 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 27 May 2014 16:10:12 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <20140527075639.259515@eggemoggin.niobe.net> References: , , <53846268.8080703@oracle.com> <20140527075639.259515@eggemoggin.niobe.net> Message-ID: <5384AAD4.5070104@oracle.com> On 27/05/14 15:56, mark.reinhold at oracle.com wrote: > 2014/5/26 20:01 -0700, michael.x.mcmahon at oracle.com: >> I think it should be throwing a SocketException rather than a >> NotYetBoundException to be consistent with ServerSocket.accept() > No, NotYetBoundException is the correct exception here. The NIO > exception hierarchy was intentionally designed to be richer than > just "SocketException". Consistency with the exceptions thrown > by the original java.net APIs is an anti-goal. > > - Mark Hi Mark, The point was clarified on a separate conversation on net-dev. The method in question refers to the channel's server socket adapter (ie an instance of java.net.ServerSocket) rather than the channel itself. What I overlooked was that the exception is being caught correctly and converted to the right exception expected by ServerSocket. Michael. From mark.reinhold at oracle.com Tue May 27 14:56:39 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 27 May 2014 07:56:39 -0700 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <53846268.8080703@oracle.com> References: , , <53846268.8080703@oracle.com> Message-ID: <20140527075639.259515@eggemoggin.niobe.net> 2014/5/26 20:01 -0700, michael.x.mcmahon at oracle.com: > I think it should be throwing a SocketException rather than a > NotYetBoundException to be consistent with ServerSocket.accept() No, NotYetBoundException is the correct exception here. The NIO exception hierarchy was intentionally designed to be richer than just "SocketException". Consistency with the exceptions thrown by the original java.net APIs is an anti-goal. - Mark From mark.reinhold at oracle.com Tue May 27 15:28:09 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 27 May 2014 08:28:09 -0700 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <5384AAD4.5070104@oracle.com> References: , <20140527075639.259515@eggemoggin.niobe.net>, <5384AAD4.5070104@oracle.com> Message-ID: <20140527082809.219902@eggemoggin.niobe.net> 2014/5/27 1:10 -0700, michael.x.mcmahon at oracle.com: > On 27/05/14 15:56, mark.reinhold at oracle.com wrote: >> 2014/5/26 20:01 -0700, michael.x.mcmahon at oracle.com: >>> I think it should be throwing a SocketException rather than a >>> NotYetBoundException to be consistent with ServerSocket.accept() >> No, NotYetBoundException is the correct exception here. The NIO >> exception hierarchy was intentionally designed to be richer than >> just "SocketException". Consistency with the exceptions thrown >> by the original java.net APIs is an anti-goal. > > The point was clarified on a separate conversation on net-dev. > The method in question refers to the channel's server socket adapter > (ie an instance of java.net.ServerSocket) rather than the channel itself. Ah, okay then -- I didn't realize that from the available context. - Mark From Alan.Bateman at oracle.com Tue May 27 16:37:37 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 17:37:37 +0100 Subject: Paths.get("").normalize() throws AIOOBE on linux In-Reply-To: References: Message-ID: <5384BF51.5040209@oracle.com> On 13/02/2013 03:24, Michael Hixson wrote: > Hello, > > I notice that on Linux, the following program throws an exception: > > import java.nio.file.Paths; > public class HelloWorld { > public static void main(String[] args) { > Paths.get("").normalize(); > } > } > > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 > at sun.nio.fs.UnixPath.normalize(UnixPath.java:508) > at HelloWorld.main(HelloWorld.java:4) > > Meanwhile on Windows, no exception is thrown. The following code prints "true": > > Path a = Paths.get(""); > Path b = a.normalize(); > System.out.println(a.equals(b)); > > Is this difference in behavior expected? > > I'm using 1.7u13 in both places. > > -Michael This mail just arrived but strangely has a timestamp of 2013. In any case, it is bug JDK-8037945, fixed in 8u20 and 9. It would be good to bring up on jdk7u-dev to get it fixed there. -Alan. From sean.coffey at oracle.com Tue May 27 18:00:11 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 27 May 2014 19:00:11 +0100 Subject: Paths.get("").normalize() throws AIOOBE on linux In-Reply-To: <5384BF51.5040209@oracle.com> References: <5384BF51.5040209@oracle.com> Message-ID: <5384D2AB.8000204@oracle.com> I'll take an action item to get this into 7u80. Thanks for brining it up! regards, Sean. On 27/05/2014 17:37, Alan Bateman wrote: > On 13/02/2013 03:24, Michael Hixson wrote: >> Hello, >> >> I notice that on Linux, the following program throws an exception: >> >> import java.nio.file.Paths; >> public class HelloWorld { >> public static void main(String[] args) { >> Paths.get("").normalize(); >> } >> } >> >> Exception in thread "main" >> java.lang.ArrayIndexOutOfBoundsException: 0 >> at sun.nio.fs.UnixPath.normalize(UnixPath.java:508) >> at HelloWorld.main(HelloWorld.java:4) >> >> Meanwhile on Windows, no exception is thrown. The following code >> prints "true": >> >> Path a = Paths.get(""); >> Path b = a.normalize(); >> System.out.println(a.equals(b)); >> >> Is this difference in behavior expected? >> >> I'm using 1.7u13 in both places. >> >> -Michael > This mail just arrived but strangely has a timestamp of 2013. > > In any case, it is bug JDK-8037945, fixed in 8u20 and 9. It would be > good to bring up on jdk7u-dev to get it fixed there. > > -Alan.