From dan.xu at oracle.com Thu Jan 3 09:31:05 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 03 Jan 2013 09:31:05 -0800 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50D48D2D.3030608@oracle.com> References: <50C66207.9050508@oracle.com> <50C87F2D.4050007@oracle.com> <50D0C4B1.40807@oracle.com> <50D0DD83.3000705@oracle.com> <50D21E1F.9000607@oracle.com> <50D48D2D.3030608@oracle.com> Message-ID: <50E5C059.9060700@oracle.com> I have made changes to my previous fix, and the latest one can be reviewed at http://cr.openjdk.java.net/~dxu/8002306/webrev.03/. Please help review it. Thanks! -Dan On 12/21/2012 08:24 AM, Alan Bateman wrote: > On 19/12/2012 20:05, Dan Xu wrote: >> Hi Alan, >> >> Your suggestion makes the code much leaner. I have updated the fix >> at, http://cr.openjdk.java.net/~dxu/8002306/webrev.02/ >> >> >> Please help review it. Thanks! >> >> -Dan > This is a lot cleaner. The read/write of ioe is subtle but as there is > a Thread.join then I think it's okay. > > At line 101 then can source or sink be null if ioe is not null? > > If I read the test correctly then PipeTester waits until it is > interrupted before it calls Pipe.open so this means it will never be > asynchronous. For both PipeTester and and the main thread then I think > it would be better to avoid the busy loop (the main thread can use > Thread.join for example). > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130103/676d13f4/attachment.html From Alan.Bateman at oracle.com Mon Jan 7 08:36:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Jan 2013 16:36:09 +0000 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50E5C059.9060700@oracle.com> References: <50C66207.9050508@oracle.com> <50C87F2D.4050007@oracle.com> <50D0C4B1.40807@oracle.com> <50D0DD83.3000705@oracle.com> <50D21E1F.9000607@oracle.com> <50D48D2D.3030608@oracle.com> <50E5C059.9060700@oracle.com> Message-ID: <50EAF979.8050301@oracle.com> On 03/01/2013 17:31, Dan Xu wrote: > I have made changes to my previous fix, and the latest one can be > reviewed at http://cr.openjdk.java.net/~dxu/8002306/webrev.03/. Please > help review it. Thanks! > > -Dan > This looks much better, I think PipeImpl is okay now. On the test then the assert in the run() method will only be effective when running with -ea. That's okay except that if it fails then AssertionError will be thrown and I don't think it will cause the test to fail. The other thing about the test is that the main thread is calling close to close the "last" Pipe instance. I don't think this is needed, the Pipe can be local to tester and it can close the source/sink always. Otherwise I think we are close to the finish line on this one, I'm happy to push it for you. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130107/bb9bd975/attachment.html From dan.xu at oracle.com Mon Jan 7 23:15:38 2013 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 07 Jan 2013 23:15:38 -0800 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50EAF979.8050301@oracle.com> References: <50C66207.9050508@oracle.com> <50C87F2D.4050007@oracle.com> <50D0C4B1.40807@oracle.com> <50D0DD83.3000705@oracle.com> <50D21E1F.9000607@oracle.com> <50D48D2D.3030608@oracle.com> <50E5C059.9060700@oracle.com> <50EAF979.8050301@oracle.com> Message-ID: <50EBC79A.70502@oracle.com> On 01/07/2013 08:36 AM, Alan Bateman wrote: > On 03/01/2013 17:31, Dan Xu wrote: >> I have made changes to my previous fix, and the latest one can be >> reviewed at http://cr.openjdk.java.net/~dxu/8002306/webrev.03/. >> Please help review it. Thanks! >> >> -Dan >> > This looks much better, I think PipeImpl is okay now. > > On the test then the assert in the run() method will only be effective > when running with -ea. That's okay except that if it fails then > AssertionError will be thrown and I don't think it will cause the test > to fail. The other thing about the test is that the main thread is > calling close to close the "last" Pipe instance. I don't think this is > needed, the Pipe can be local to tester and it can close the > source/sink always. > > Otherwise I think we are close to the finish line on this one, I'm > happy to push it for you. > > -Alan I was not aware that the assertion error could not cause the test to fail. Thanks for pointing out. I modified the test and uploaded it to http://cr.openjdk.java.net/~dxu/8002306/webrev.04/. Please help take a look. Thanks! -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130107/82bf0d7e/attachment.html From Alan.Bateman at oracle.com Tue Jan 8 08:02:52 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Jan 2013 16:02:52 +0000 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50EBC79A.70502@oracle.com> References: <50C66207.9050508@oracle.com> <50C87F2D.4050007@oracle.com> <50D0C4B1.40807@oracle.com> <50D0DD83.3000705@oracle.com> <50D21E1F.9000607@oracle.com> <50D48D2D.3030608@oracle.com> <50E5C059.9060700@oracle.com> <50EAF979.8050301@oracle.com> <50EBC79A.70502@oracle.com> Message-ID: <50EC432C.8050007@oracle.com> On 08/01/2013 07:15, Dan Xu wrote: > > I was not aware that the assertion error could not cause the test to > fail. Thanks for pointing out. I modified the test and uploaded it to > http://cr.openjdk.java.net/~dxu/8002306/webrev.04/. Please help take a > look. Thanks! Thanks, this looks much better now. One small improvement for the test would be not to throw an IOException when the interrupt status is detected to be reset but rather just save it ("ie" could be an Exception). If you agree then I can make that (tiny) change before I push it for you later today. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130108/2007976b/attachment.html From forax at univ-mlv.fr Tue Jan 8 08:10:51 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 08 Jan 2013 17:10:51 +0100 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50EC432C.8050007@oracle.com> References: <50C66207.9050508@oracle.com> <50C87F2D.4050007@oracle.com> <50D0C4B1.40807@oracle.com> <50D0DD83.3000705@oracle.com> <50D21E1F.9000607@oracle.com> <50D48D2D.3030608@oracle.com> <50E5C059.9060700@oracle.com> <50EAF979.8050301@oracle.com> <50EBC79A.70502@oracle.com> <50EC432C.8050007@oracle.com> Message-ID: <50EC450B.7030907@univ-mlv.fr> On 01/08/2013 05:02 PM, Alan Bateman wrote: > On 08/01/2013 07:15, Dan Xu wrote: >> >> I was not aware that the assertion error could not cause the test to >> fail. Thanks for pointing out. I modified the test and uploaded it to >> http://cr.openjdk.java.net/~dxu/8002306/webrev.04/. Please help take >> a look. Thanks! > Thanks, this looks much better now. > > One small improvement for the test would be not to throw an > IOException when the interrupt status is detected to be reset but > rather just save it ("ie" could be an Exception). If you agree then I > can make that (tiny) change before I push it for you later today. > > -Alan > I think ioe should be volatile ? R?mi From Alan.Bateman at oracle.com Tue Jan 8 08:17:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Jan 2013 16:17:43 +0000 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50EC450B.7030907@univ-mlv.fr> References: <50C66207.9050508@oracle.com> <50C87F2D.4050007@oracle.com> <50D0C4B1.40807@oracle.com> <50D0DD83.3000705@oracle.com> <50D21E1F.9000607@oracle.com> <50D48D2D.3030608@oracle.com> <50E5C059.9060700@oracle.com> <50EAF979.8050301@oracle.com> <50EBC79A.70502@oracle.com> <50EC432C.8050007@oracle.com> <50EC450B.7030907@univ-mlv.fr> Message-ID: <50EC46A7.9010008@oracle.com> On 08/01/2013 16:10, Remi Forax wrote: > On 01/08/2013 05:02 PM, Alan Bateman wrote: >> On 08/01/2013 07:15, Dan Xu wrote: >>> >>> I was not aware that the assertion error could not cause the test to >>> fail. Thanks for pointing out. I modified the test and uploaded it >>> to http://cr.openjdk.java.net/~dxu/8002306/webrev.04/. Please help >>> take a look. Thanks! >> Thanks, this looks much better now. >> >> One small improvement for the test would be not to throw an >> IOException when the interrupt status is detected to be reset but >> rather just save it ("ie" could be an Exception). If you agree then I >> can make that (tiny) change before I push it for you later today. >> >> -Alan >> > > I think ioe should be volatile ? It might be clearer although I think we are okay because of the Thread.join. -Alan. From dan.xu at oracle.com Tue Jan 8 10:43:15 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 08 Jan 2013 10:43:15 -0800 Subject: Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win] In-Reply-To: <50EC46A7.9010008@oracle.com> References: <50C66207.9050508@oracle.com> <50C87F2D.4050007@oracle.com> <50D0C4B1.40807@oracle.com> <50D0DD83.3000705@oracle.com> <50D21E1F.9000607@oracle.com> <50D48D2D.3030608@oracle.com> <50E5C059.9060700@oracle.com> <50EAF979.8050301@oracle.com> <50EBC79A.70502@oracle.com> <50EC432C.8050007@oracle.com> <50EC450B.7030907@univ-mlv.fr> <50EC46A7.9010008@oracle.com> Message-ID: <50EC68C3.6080004@oracle.com> On 01/08/2013 08:17 AM, Alan Bateman wrote: > On 08/01/2013 16:10, Remi Forax wrote: >> On 01/08/2013 05:02 PM, Alan Bateman wrote: >>> On 08/01/2013 07:15, Dan Xu wrote: >>>> >>>> I was not aware that the assertion error could not cause the test >>>> to fail. Thanks for pointing out. I modified the test and uploaded >>>> it to http://cr.openjdk.java.net/~dxu/8002306/webrev.04/. Please >>>> help take a look. Thanks! >>> Thanks, this looks much better now. >>> >>> One small improvement for the test would be not to throw an >>> IOException when the interrupt status is detected to be reset but >>> rather just save it ("ie" could be an Exception). If you agree then >>> I can make that (tiny) change before I push it for you later today. >>> >>> -Alan >>> >> >> I think ioe should be volatile ? > It might be clearer although I think we are okay because of the > Thread.join. > > -Alan. The improvement makes the test code cleaner. I agree with that. Thank you for reviewing my changes. -Dan From youdwei at linux.vnet.ibm.com Wed Jan 9 21:52:54 2013 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Thu, 10 Jan 2013 13:52:54 +0800 Subject: Using OP_CONNECT with Selector.select causes selector to fire repeatedly In-Reply-To: <50AF2E56.1010205@linux.vnet.ibm.com> References: <4FAA1C40.6040709@linux.vnet.ibm.com> <4FB2BF30.9060902@oracle.com> <4FC72201.7090307@linux.vnet.ibm.com> <4FCDB0B2.1040902@linux.vnet.ibm.com> <4FDEDAD7.60908@linux.vnet.ibm.com> <4FDF10B5.9070703@oracle.com> <4FE17A08.7010801@linux.vnet.ibm.com> <4FE17EBD.6060704@oracle.com> <50AF2E56.1010205@linux.vnet.ibm.com> Message-ID: <50EE5736.6060504@linux.vnet.ibm.com> Hi Alan, Any suggestion about this webrev[1]? [1] http://cr.openjdk.java.net/~youdwei/ojdk-317/webrev.02/ Thanks a lot! On 11/23/2012 04:05 PM, Deven You wrote: > Hi All, > > I just made a new java doc change[1] for this problem, could you take > a look and give your suggestions so we may improve it. > > [1] http://cr.openjdk.java.net/~youdwei/ojdk-317/webrev.02/ > > > Thanks a lot! > On 06/20/2012 03:41 PM, Alan Bateman wrote: >> On 20/06/2012 08:21, Deven You wrote: >>> Hi Alan and Jonathan, >>> >>> I have tried modifying the Selector.select() javadoc[1] so that >>> users can get clear information about the behavior of dealing with >>> OP_CONNECT. >>> >>> Could you or any one else take a look at review it. >> I'm really busy at the moment and do not have time to spend on this. >> It will mostly likely require updates to Selector and SelectionKey's >> class description, a note in SocketChannel connect might be useful too. >> >> -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130110/157a1c35/attachment.html From Alan.Bateman at oracle.com Fri Jan 11 02:01:21 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Jan 2013 10:01:21 +0000 Subject: 8005566: (fs) test/java/nio/file/Files/Misc.java failing (sol) Message-ID: <50EFE2F1.8030003@oracle.com> I need a reviewer for a small change to the Solaris-specific code for decoding NFSv4 ACLs. This is required because of a recent update to the kernel that exposes an incorrect assumption in this code. When we read an ACL with facl(ACE_GETACL) then the decoding assumed that an ACE with a uid of -1 is a special "who", meaning owner, group or everyone. The fix removes the assumption so that it always looks at the ACE flags to determine if the "who" is special. The webrev with the changes are here: http://cr.openjdk.java.net/~alanb/8005566/webrev/ I don't propose to add any additional tests as all existing tests will fail on ZFS without this fix. -Alan. From chris.hegarty at oracle.com Fri Jan 11 03:22:51 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Jan 2013 11:22:51 +0000 Subject: 8005566: (fs) test/java/nio/file/Files/Misc.java failing (sol) In-Reply-To: <50EFE2F1.8030003@oracle.com> References: <50EFE2F1.8030003@oracle.com> Message-ID: <50EFF60B.2060903@oracle.com> Looks fine to me. Trivially, still a minor type, uitn32_t -> uint32_t -Chris. On 11/01/2013 10:01, Alan Bateman wrote: > > I need a reviewer for a small change to the Solaris-specific code for > decoding NFSv4 ACLs. This is required because of a recent update to the > kernel that exposes an incorrect assumption in this code. > > When we read an ACL with facl(ACE_GETACL) then the decoding assumed that > an ACE with a uid of -1 is a special "who", meaning owner, group or > everyone. The fix removes the assumption so that it always looks at the > ACE flags to determine if the "who" is special. The webrev with the > changes are here: > > http://cr.openjdk.java.net/~alanb/8005566/webrev/ > > I don't propose to add any additional tests as all existing tests will > fail on ZFS without this fix. > > -Alan. From Alan.Bateman at oracle.com Fri Jan 11 04:17:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Jan 2013 12:17:28 +0000 Subject: 8005566: (fs) test/java/nio/file/Files/Misc.java failing (sol) In-Reply-To: <50EFF60B.2060903@oracle.com> References: <50EFE2F1.8030003@oracle.com> <50EFF60B.2060903@oracle.com> Message-ID: <50F002D8.7050300@oracle.com> On 11/01/2013 11:22, Chris Hegarty wrote: > Looks fine to me. > > Trivially, still a minor type, uitn32_t -> uint32_t > > -Chris. Thanks, I'll fix that typo in the comment before I push this. -Alan. From zhouyx at linux.vnet.ibm.com Sun Jan 13 21:28:16 2013 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Mon, 14 Jan 2013 13:28:16 +0800 Subject: A race problem about select in a small time window In-Reply-To: <50D4863A.5000109@oracle.com> References: <50D4863A.5000109@oracle.com> Message-ID: Hello Rob, Do you have some time to take a look at this issue ? On Fri, Dec 21, 2012 at 11:54 PM, Alan Bateman wrote: > > I don't have cycles to look at this one (too much going on for M6) but Rob > McKenna (cc'ed) might. > > > On 17/12/2012 08:56, Sean Chou wrote: > >> Hello , >> >> This is the detail problem, there is a small time window in which a 3 >> threads race makes select() always return 0 without blocking. >> >> I wrote a testcase(http://cr.openjdk.**java.net/~zhouyx/OJDK-714/** >> webrev0.2/ < >> http://cr.openjdk.java.net/%**7Ezhouyx/OJDK-714/webrev0.2/>) >> which needs to modify the lib code to reproduce, because the time windows >> is small. >> >> >> The reproduce scenario is described in follow, use Tx for thread x: >> >> 1. T1 (the user code) is selecting a channel(suppose C), it just returns >> from native select function, and niolib select method is checking if the >> returned channel is interested in the event, then 2 happens; >> 2. T2 is closing channel C, it just set the open variable to false but >> not yet closed the channel actually, and then 3 happens; >> 3. T3 set the interedOps of the channel to 0. // 0 means the channel is >> not interested in anything, the channel will be put into cancel list >> normally. >> >> In this senario, T1 returns from select, and return 0 which means no >> channel is selected(because the channel C returned from native invocation >> has nothing insterested in, it is not returned to application). Then T1 >> goes to invoke select again(usually in a loop, this is how select is >> designed to be used). In normal case, select method checks if any channels >> those should be cancelled and remove them from the set to be selected. >> Then, goes to native select function. >> >> The problem is: select method first checks if the channel is closed, if >> it is closed, select method doesn't put it into cancel list. >> >> In above senario, channel C is in close state, but not closed indeed, and >> setInteredOps to 0(which means cancel). So select method doesn't put C into >> cancel list(due to the problem) which means the native select set still >> contains channel C . So the native select always return C and nio select >> always return 0. Until the channel is finally closed. >> >> >> The testcase: http://cr.openjdk.java.net/~**zhouyx/OJDK-714/webrev0.2/< >> http://cr.openjdk.java.net/%**7Ezhouyx/OJDK-714/webrev0.2/ >> > >> >> A working fix: http://cr.openjdk.java.net/~**zhouyx/OJDK-714/webrev_fix/< >> http://cr.openjdk.java.net/%**7Ezhouyx/OJDK-714/webrev_fix/ >> > >> >> >> Please have a look. >> >> >> > -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130114/274a0685/attachment.html From Alan.Bateman at oracle.com Mon Jan 14 00:53:21 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jan 2013 08:53:21 +0000 Subject: A race problem about select in a small time window In-Reply-To: References: <50D4863A.5000109@oracle.com> Message-ID: <50F3C781.9070304@oracle.com> On 14/01/2013 05:28, Sean Chou wrote: > > > Do you have some time to take a look at this issue ? > I haven't had time, I expect others are very busy with M6 too. As there is bug fixing after M6 then I think it would be a good time to look at it then (it's one of these issues that requires a lot of time to analyze, it's great that you have a way to duplicate it and it's possible your fix is correctly but it needs time to study first). -Alan From rob.mckenna at oracle.com Mon Jan 14 13:10:45 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 14 Jan 2013 21:10:45 +0000 Subject: A race problem about select in a small time window In-Reply-To: <50D4863A.5000109@oracle.com> References: <50D4863A.5000109@oracle.com> Message-ID: <50F47455.1000307@oracle.com> Apologies folks, I managed to overlook this completely. Sean, its on my radar and I'll get back to you soon. -Rob On 21/12/12 15:54, Alan Bateman wrote: > > I don't have cycles to look at this one (too much going on for M6) but > Rob McKenna (cc'ed) might. > > On 17/12/2012 08:56, Sean Chou wrote: >> Hello , >> >> This is the detail problem, there is a small time window in which a 3 >> threads race makes select() always return 0 without blocking. >> >> I wrote a >> testcase(http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/ >> ) which >> needs to modify the lib code to reproduce, because the time windows >> is small. >> >> The reproduce scenario is described in follow, use Tx for thread x: >> >> 1. T1 (the user code) is selecting a channel(suppose C), it just >> returns from native select function, and niolib select method is >> checking if the returned channel is interested in the event, then 2 >> happens; >> 2. T2 is closing channel C, it just set the open variable to false >> but not yet closed the channel actually, and then 3 happens; >> 3. T3 set the interedOps of the channel to 0. // 0 means the channel >> is not interested in anything, the channel will be put into cancel >> list normally. >> >> In this senario, T1 returns from select, and return 0 which means no >> channel is selected(because the channel C returned from native >> invocation has nothing insterested in, it is not returned to >> application). Then T1 goes to invoke select again(usually in a loop, >> this is how select is designed to be used). In normal case, select >> method checks if any channels those should be cancelled and remove >> them from the set to be selected. Then, goes to native select function. >> >> The problem is: select method first checks if the channel is closed, >> if it is closed, select method doesn't put it into cancel list. >> >> In above senario, channel C is in close state, but not closed indeed, >> and setInteredOps to 0(which means cancel). So select method doesn't >> put C into cancel list(due to the problem) which means the native >> select set still contains channel C . So the native select always >> return C and nio select always return 0. Until the channel is finally >> closed. >> >> >> The testcase: http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/ >> >> >> A working fix: >> http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev_fix/ >> >> >> >> Please have a look. >> >> > From andrewscully at gmail.com Thu Jan 17 03:00:21 2013 From: andrewscully at gmail.com (Andrew Scully) Date: Thu, 17 Jan 2013 11:00:21 +0000 Subject: NIO optimization suggestions Message-ID: Hi, After some recent ?code surfing? of JDK 7, I have some observations regarding some aspects of the NIO implementation, which may or may not be correct or of use. *java.nio.channels.Channels.java* Channels.ReadableByteChannelImpl (a stream -> channel wrapper created by a call to Channels.newChannel(InputStream) when the stream is not of type FileInputStream) seems to have room for an optimisation, whereby the read function may check the destination buffer?s hasArray value. If true, that backing array may be directly transferred to, rather than going via an intermediary byte array as it does in the default path. Furthermore, the 8192 TRANSFER_SIZE used here to batch the transfer seems to be arbitrary, given the circumstances. I appreciate it is a probably an attempt to align with the 4096 typical HDD segment / socket buffer size, but the wrapped stream may not have anything to do with such a resource. It could be a ByteArrayInputStream for instance. I have had success using the size of the destination buffer as a hint, instead, since memory has already been safely allocated for the destination buffer. In many cases, the transfer could be performed as a single bulk operation. The ?open? private boolean here appears to be unused. *sun.nio.ch**.FileChannelImpl.java* FileChannelImpl attempts to use sendFile (or the underlying OS?s equivalent) for transferTo, but not for transferFrom. In cases where both file descriptors refer to a FileChannel, surely zero-copy could be used on many operating systems? I would have thought that, in some cases at least, the source and destination arguments could be swapped and the existing JNI call used, though I could be wrong. >From the sendFile(3) man page: ?The in_fd argument should be a file descriptor to a regular file opened for reading. See open(2). The out_fd argument should be a file descriptor to a regular file opened for writing or? Congrats on fixing http://bugs.sun.com/view_bug.do?bug_id=6431344, but I suspect that the MAPPED_TRANSFER_SIZE being used in transferToTrustedChannel is on the large side. Buffers of this size are still a vulnerability that could be exploited by a sufficient volume of concurrent requests. Much of the data I?ve seen suggests that the ?sweet spot? for this kind of transfer is around about the 256KB mark, though this kind of data has a tendency to be totally unreliable! Cheers, Andy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130117/e4eca7a6/attachment.html From Alan.Bateman at oracle.com Thu Jan 17 10:12:22 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Jan 2013 18:12:22 +0000 Subject: 6939260: (fs) BasicFileAttributes.lastModifiedTime() should return last modified time with higher precision Message-ID: <50F83F06.5040609@oracle.com> File timestamps are currently returned with second resolution on Solaris/Linux, this is because this is what stat(2) and fstat(2) give us. I'd like to update this to use the nanosecond values where available. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/6939260/webrev/ Thanks, Alan. From chris.hegarty at oracle.com Fri Jan 18 03:21:04 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 18 Jan 2013 11:21:04 +0000 Subject: 6939260: (fs) BasicFileAttributes.lastModifiedTime() should return last modified time with higher precision In-Reply-To: <50F83F06.5040609@oracle.com> References: <50F83F06.5040609@oracle.com> Message-ID: <50F93020.7010904@oracle.com> Looks fine to me. I admit that I'm not familiar with "_POSIX_C_SOURCE >= 200809L", but I guess this is just checking that the nano second time is available on more recent glic/posix versions on Linux. -Chris. On 17/01/2013 18:12, Alan Bateman wrote: > > File timestamps are currently returned with second resolution on > Solaris/Linux, this is because this is what stat(2) and fstat(2) give > us. I'd like to update this to use the nanosecond values where available. > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/6939260/webrev/ > > Thanks, > > Alan. From Alan.Bateman at oracle.com Fri Jan 18 03:28:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Jan 2013 11:28:07 +0000 Subject: 6939260: (fs) BasicFileAttributes.lastModifiedTime() should return last modified time with higher precision In-Reply-To: <50F93020.7010904@oracle.com> References: <50F83F06.5040609@oracle.com> <50F93020.7010904@oracle.com> Message-ID: <50F931C7.2040200@oracle.com> On 18/01/2013 11:21, Chris Hegarty wrote: > Looks fine to me. > > I admit that I'm not familiar with "_POSIX_C_SOURCE >= 200809L", but I > guess this is just checking that the nano second time is available on > more recent glic/posix versions on Linux. Thanks for looking at this. The fields were added in POSIX.1-2008. The reason for also using them on Solaris is that Solaris 10 pre-dates this but provides the fields anyway. -Alan. From dan.xu at oracle.com Mon Jan 21 23:25:25 2013 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 21 Jan 2013 23:25:25 -0800 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code Message-ID: <50FE3EE5.20600@oracle.com> Hi, Interruptible I/O on Solaris has been highly problematicand undercut portability. And the long term plan is to remove it completely from JDK. In JDK6, the VM option, UseVMInterruptibleIO, was introduced as part of a phase-out plan to allow developers/customers to disable it. In JDK7, the default value of UseVMInterruptibleIO flag was changed to"false" to make Solaris blockingI/O operations uninterruptible by Java thread interruptsby default. The last stepof this phase-out plan is to remove the feature completely. And it is good to do it now in JDK8. In this fix, I removed all related codes in IO area by replacing JVM_* functions with direct system calls. Please help review the proposed fix. Similar changes in networking area will be done via a different bug. Bug: https://jbs.oracle.com/bugs/browse/JDK-8001334 webrev: http://cr.openjdk.java.net/~dxu/8001334/webrev.00/ Reference: http://ccc.us.oracle.com/6423562 http://ccc.us.oracle.com/6554406 Best, -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130121/b6df5038/attachment.html From Alan.Bateman at oracle.com Wed Jan 23 07:27:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2013 15:27:16 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <50FE3EE5.20600@oracle.com> References: <50FE3EE5.20600@oracle.com> Message-ID: <51000154.5040607@oracle.com> Dan - I'm going to move this review to core-libs-dev, hope that is okay. On 22/01/2013 07:25, Dan Xu wrote: > Hi, > > Interruptible I/O on Solaris has been highly problematicand undercut > portability. And the long term plan is to remove it completely from > JDK. In JDK6, the VM option, UseVMInterruptibleIO, was introduced as > part of a phase-out plan to allow developers/customers to disable it. > In JDK7, the default value of UseVMInterruptibleIO flag was changed > to"false" to make Solaris blockingI/O operations uninterruptible by > Java thread interruptsby default. > > The last stepof this phase-out plan is to remove the feature > completely. And it is good to do it now in JDK8. In this fix, I > removed all related codes in IO area by replacing JVM_* functions with > direct system calls. Please help review the proposed fix. Similar > changes in networking area will be done via a different bug. > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8001334 > webrev: http://cr.openjdk.java.net/~dxu/8001334/webrev.00/ > > > Reference: > http://ccc.us.oracle.com/6423562 > http://ccc.us.oracle.com/6554406 > > Best, > > -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130123/53619cb1/attachment.html From dan.xu at oracle.com Wed Jan 23 08:02:08 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 23 Jan 2013 08:02:08 -0800 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <51000154.5040607@oracle.com> References: <50FE3EE5.20600@oracle.com> <51000154.5040607@oracle.com> Message-ID: <51000980.7090001@oracle.com> Sure,Alan. I'd like to get suggestions from all expertsto help find out potential issues if anyexists.Thanks! -Dan On 01/23/2013 07:27 AM, Alan Bateman wrote: > Dan - I'm going to move this review to core-libs-dev, hope that is okay. > > On 22/01/2013 07:25, Dan Xu wrote: >> Hi, >> >> Interruptible I/O on Solaris has been highly problematicand undercut >> portability. And the long term plan is to remove it completely from >> JDK. In JDK6, the VM option, UseVMInterruptibleIO, was introduced as >> part of a phase-out plan to allow developers/customers to disable it. >> In JDK7, the default value of UseVMInterruptibleIO flag was changed >> to"false" to make Solaris blockingI/O operations uninterruptible by >> Java thread interruptsby default. >> >> The last stepof this phase-out plan is to remove the feature >> completely. And it is good to do it now in JDK8. In this fix, I >> removed all related codes in IO area by replacing JVM_* functions >> with direct system calls. Please help review the proposed fix. >> Similar changes in networking area will be done via a different bug. >> >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8001334 >> webrev: http://cr.openjdk.java.net/~dxu/8001334/webrev.00/ >> >> >> Reference: >> http://ccc.us.oracle.com/6423562 >> http://ccc.us.oracle.com/6554406 >> >> Best, >> >> -Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130123/0fa58ee2/attachment-0001.html From Alan.Bateman at oracle.com Wed Jan 23 08:06:25 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2013 16:06:25 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <51000980.7090001@oracle.com> References: <50FE3EE5.20600@oracle.com> <51000154.5040607@oracle.com> <51000980.7090001@oracle.com> Message-ID: <51000A81.9040309@oracle.com> On 23/01/2013 16:02, Dan Xu wrote: > Sure,Alan. > > I'd like to get suggestions from all expertsto help find out potential > issues if anyexists.Thanks! > > -Dan This is good work and I plan to review it soon. One reason for moving it to core-libs-dev is that it impacts porting so they may be others that want to comment or help review. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130123/8e0d4ec0/attachment.html From dan.xu at oracle.com Wed Jan 23 08:29:35 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 23 Jan 2013 08:29:35 -0800 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <51000A81.9040309@oracle.com> References: <50FE3EE5.20600@oracle.com> <51000154.5040607@oracle.com> <51000980.7090001@oracle.com> <51000A81.9040309@oracle.com> Message-ID: <51000FEF.4010606@oracle.com> I see. Thanks! As it also contains make file changes, I think I also need post it to build-dev mailing list for review. -Dan On Wed 23 Jan 2013 08:06:25 AM PST, Alan Bateman wrote: > On 23/01/2013 16:02, Dan Xu wrote: >> Sure,Alan. >> >> I'd like to get suggestions from all expertsto help find out >> potential issues if anyexists.Thanks! >> >> -Dan > This is good work and I plan to review it soon. One reason for moving > it to core-libs-dev is that it impacts porting so they may be others > that want to comment or help review. > > -Alan > > From dingxmin at linux.vnet.ibm.com Tue Jan 29 23:21:43 2013 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Wed, 30 Jan 2013 15:21:43 +0800 Subject: Bug: SelectionKey.interestOps ignores interestOps on Windows Message-ID: <5108CA07.7080007@linux.vnet.ibm.com> Hi guys, There is a bug in nio selector on Windows which is reported by bug 4863822 (closed now) and 6429204 (open). The issue happens on Windows, where two threads, one doing a channel registration/deregistration with a selector and the other setting interestOps on one of the channels registered to the selector. The thread doing select() goes eventually to WindowsSelectorImpl.implDereg() that rearranges SelectionKeyImpls in array channelArray and then adjusts entries in pollWrapper. Since implDereg method does not synchronize rearrangement of channelArray and accessing pollWrapper, the other thread calling interestOps has a possibility of updating ops on the already deleted fd in the poll array. The problem can be manifested by the test case in the webrev review [1]. The test loops a large number of times in thread 1 trying to change interest set for a SelectionKey. The other thread(main thread) should be able to sense the change and notify thread 1 within a short period of time. I admit that the test is not deterministic, which means it has a chance to pass with current JDK. I think it would be better having a bootstrapped class to reproduce the problem in a stable way but don't have any idea whether jtreg can achieve this. Solution to the problem is quite straightforward. See patch in [1]. Simply extending closeLock sync scope from implRegister, putEventOps, implClose to implDereg. I have concern on the scope of lock closeLock. In the patch I provided, I put synchronized(closeLock) within if statement. This resolves the issue and also minimizes the potential performance degradation. However, in class WindowsSelectorImpl, closeLock should protect other variables such as totalChannels, fdMap, keys and selectedKeys. So would it make more sense to increase scope to before deregister(ski) call? Thanks in advance for any comments and review offered. [1] http://cr.openjdk.java.net/~dingxmin/6429204/webrev.00/ Best regards, Frank From Alan.Bateman at oracle.com Wed Jan 30 11:54:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Jan 2013 19:54:24 +0000 Subject: Bug: SelectionKey.interestOps ignores interestOps on Windows In-Reply-To: <5108CA07.7080007@linux.vnet.ibm.com> References: <5108CA07.7080007@linux.vnet.ibm.com> Message-ID: <51097A70.2040104@oracle.com> On 30/01/2013 07:21, Frank Ding wrote: > Hi guys, > There is a bug in nio selector on Windows which is reported by bug > 4863822 (closed now) and 6429204 (open). > > The issue happens on Windows, where two threads, one doing a channel > registration/deregistration with a selector and the other setting > interestOps on one of the channels registered to the selector. > The thread doing select() goes eventually to > WindowsSelectorImpl.implDereg() that rearranges SelectionKeyImpls in > array channelArray and then adjusts entries in pollWrapper. Since > implDereg method does not synchronize rearrangement of channelArray > and accessing pollWrapper, the other thread calling interestOps has a > possibility of updating ops on the already deleted fd in the poll array. > > The problem can be manifested by the test case in the webrev review > [1]. The test loops a large number of times in thread 1 trying to > change interest set for a SelectionKey. The other thread(main thread) > should be able to sense the change and notify thread 1 within a short > period of time. I admit that the test is not deterministic, which > means it has a chance to pass with current JDK. I think it would be > better having a bootstrapped class to reproduce the problem in a > stable way but don't have any idea whether jtreg can achieve this. > Solution to the problem is quite straightforward. See patch in > [1]. Simply extending closeLock sync scope from implRegister, > putEventOps, implClose to implDereg. I have concern on the scope of > lock closeLock. In the patch I provided, I put > synchronized(closeLock) within if statement. This resolves the issue > and also minimizes the potential performance degradation. However, in > class WindowsSelectorImpl, closeLock should protect other variables > such as totalChannels, fdMap, keys and selectedKeys. So would it make > more sense to increase scope to before deregister(ski) call? > > Thanks in advance for any comments and review offered. > > [1] http://cr.openjdk.java.net/~dingxmin/6429204/webrev.00/ Yes, there is a problem here. Most of the original issue was fixed by the changes in 5025260 but implDereg was left to 6429204. It needs a bit of study (to remember how the synchronization is specified and implemented in this Selector) but I think the synchronization block does need to go further to include down to (and including) the fdMap.remove. The test will be a bit of clean-up. Tests for Selector go into test/java/nio/channels/Selector. A possible name for the test is RacyDeregister (we've avoiding putting bug IDs into the test names here). jtreg tests aren't supposed to use System.exit so I think it needs a better way to terminate. Also it the try/catch to throw RuntimeException at the end isn't needed. Otherwise I think it just needs clean-up and to make sure that the Selector and SocketChannels are closed. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130130/f7e98899/attachment.html