From Alan.Bateman at oracle.com Tue Aug 6 22:21:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Aug 2013 22:21:17 -0700 Subject: Deadlock in clinit for sun.nio.ch.Util/IOUtil In-Reply-To: References: Message-ID: <5201D94D.3000407@oracle.com> On 06/08/2013 15:21, Jeremy Manson wrote: > : > > We can eagerly do class init as a workaround, but that seems less than > ideal. It looks easy enough to fix - just move the stuff in Util.load() > into IOUtil somewhere, and don't call back to Util from IOUtil.. > But I'll defer to the experts. > Thanks for the mail, I'll create a bug for this. From an initial look then moving it to IOUtil should resolve this as Util doesn't define any native methods and so doesn't care if the native library has been loaded. -Alan. From Alan.Bateman at oracle.com Wed Aug 7 19:04:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Aug 2013 19:04:18 -0700 Subject: Deadlock in clinit for sun.nio.ch.Util/IOUtil In-Reply-To: References: <5201D94D.3000407@oracle.com> Message-ID: <5202FCA2.2060806@oracle.com> On 07/08/2013 09:56, Jeremy Manson wrote: > Thanks, Alan. Do please ping back when you've created the bug (I'm > not on nio-dev), because I'd like to track it (so we can remove our > workaround when the time comes). The bug is: 8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil A webrev coming soon, I just want to ensure that the tests pass on all platforms. -Alan. From yiming.wang at oracle.com Tue Aug 13 04:24:49 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 13 Aug 2013 19:24:49 +0800 Subject: Review request for test bug 8015765: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java Message-ID: <520A1781.3060305@oracle.com> Hi, Please help to review the fix below for the bug https://jbs.oracle.com/bugs/browse/JDK-8015765. http://cr.openjdk.java.net/~ewang/8015765/webrev.00/ As the test is depended on thread schedule, it may fail intermittently.The fix is to adjust thread priority, and increase thread sleep duration, to make it more stable. Thanks, Eric From yiming.wang at oracle.com Tue Aug 13 04:29:17 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 13 Aug 2013 19:29:17 +0800 Subject: Review request for bug 8015762: java/nio/channels/DatagramChannel/AdaptDatagramSocket.java fails intermittently Message-ID: <520A188D.2070808@oracle.com> Hi, Please help to review the fix below for bug https://jbs.oracle.com/bugs/browse/JDK-8015762. http://cr.openjdk.java.net/~ewang/8015762/webrev.00/ The test AdaptDatagramSocket fails intermittently as it runs depended on thread schedule. The fix to adjust the thread priority and sleep time to make the test more stable. Thanks, Eric From chris.hegarty at oracle.com Tue Aug 13 06:48:59 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 13 Aug 2013 14:48:59 +0100 Subject: Review request for test bug 8015765: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java In-Reply-To: <520A1781.3060305@oracle.com> References: <520A1781.3060305@oracle.com> Message-ID: <520A394B.60102@oracle.com> This test looks a little bizarre, and certainly racy. What you have done should make the test more reliable. I noticed that the server socket channel is only closed if a socket is accepted. I think it should be closed always, regardless of whether a socket is accepted or not. Though this is not directly related to your changes. -Chris On 08/13/2013 12:24 PM, Eric Wang wrote: > Hi, > > Please help to review the fix below for the bug > https://jbs.oracle.com/bugs/browse/JDK-8015765. > http://cr.openjdk.java.net/~ewang/8015765/webrev.00/ > > As the test is depended on thread schedule, it may fail > intermittently.The fix is to adjust thread priority, and increase thread > sleep duration, to make it more stable. > > Thanks, > Eric From Alan.Bateman at oracle.com Tue Aug 13 07:01:48 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Aug 2013 15:01:48 +0100 Subject: Review request for test bug 8015765: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java In-Reply-To: <520A1781.3060305@oracle.com> References: <520A1781.3060305@oracle.com> Message-ID: <520A3C4C.6040609@oracle.com> On 13/08/2013 12:24, Eric Wang wrote: > Hi, > > Please help to review the fix below for the bug > https://jbs.oracle.com/bugs/browse/JDK-8015765. > http://cr.openjdk.java.net/~ewang/8015765/webrev.00/ > > As the test is depended on thread schedule, it may fail > intermittently.The fix is to adjust thread priority, and increase > thread sleep duration, to make it more stable. > > Thanks, > Eric This a JDK 1.4 era test so thanks for looking at it. The change looks okay to me although I think I'd leave out the changes to the thread priority as that shouldn't be needed. -Alan. From Alan.Bateman at oracle.com Tue Aug 13 13:55:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Aug 2013 21:55:12 +0100 Subject: Review request for bug 8015762: java/nio/channels/DatagramChannel/AdaptDatagramSocket.java fails intermittently In-Reply-To: <520A188D.2070808@oracle.com> References: <520A188D.2070808@oracle.com> Message-ID: <520A9D30.8020107@oracle.com> On 13/08/2013 12:29, Eric Wang wrote: > Hi, > > Please help to review the fix below for bug > https://jbs.oracle.com/bugs/browse/JDK-8015762. > http://cr.openjdk.java.net/~ewang/8015762/webrev.00/ > > The test AdaptDatagramSocket fails intermittently as it runs depended > on thread schedule. The fix to adjust the thread priority and sleep > time to make the test more stable. I think I need to understand this issue further to properly review this. >From the stack trace in the bug report then it looks like it's the "test(address, 5000, false, false)" case that is timing out. Is it definitely the case that is failing (intermittently) and have you managed to duplicate it? -Alan From yiming.wang at oracle.com Wed Aug 14 20:22:05 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 15 Aug 2013 11:22:05 +0800 Subject: Review request for test bug 8015765: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java In-Reply-To: <520A394B.60102@oracle.com> References: <520A1781.3060305@oracle.com> <520A394B.60102@oracle.com> Message-ID: <520C495D.90501@oracle.com> Hi Chris & Alan, Thanks for the review, I have updated the code based on your suggestions. Please help to review again, Thanks! http://cr.openjdk.java.net/~ewang/8015765/webrev.01/ Eric On 2013/8/13 21:48, Chris Hegarty wrote: > This test looks a little bizarre, and certainly racy. What you have > done should make the test more reliable. > > I noticed that the server socket channel is only closed if a socket is > accepted. I think it should be closed always, regardless of whether a > socket is accepted or not. Though this is not directly related to your > changes. > > -Chris > > On 08/13/2013 12:24 PM, Eric Wang wrote: >> Hi, >> >> Please help to review the fix below for the bug >> https://jbs.oracle.com/bugs/browse/JDK-8015765. >> http://cr.openjdk.java.net/~ewang/8015765/webrev.00/ >> >> As the test is depended on thread schedule, it may fail >> intermittently.The fix is to adjust thread priority, and increase thread >> sleep duration, to make it more stable. >> >> Thanks, >> Eric From david.holmes at oracle.com Wed Aug 14 21:29:24 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Aug 2013 14:29:24 +1000 Subject: Review request for test bug 8015765: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java In-Reply-To: <520C495D.90501@oracle.com> References: <520A1781.3060305@oracle.com> <520A394B.60102@oracle.com> <520C495D.90501@oracle.com> Message-ID: <520C5924.1090308@oracle.com> Eric, Glad to hear Thread priority changes are gone :) (Just forget Thread priority even exists - it is meaningless.) Minor style nit: 82 try (ServerSocketChannel ssc = ServerSocketChannel.open(); ServerSocket sso = ssc.socket();) { Use a line per declaration. I don't know what the key aspects of this test are but I suspect that "clientStarted" really needs to indicate more than the fact the thread has started execution of its run() method - ie it should come as close as possible to the action that the main part of the test depends upon. David On 15/08/2013 1:22 PM, Eric Wang wrote: > Hi Chris & Alan, > > Thanks for the review, I have updated the code based on your > suggestions. Please help to review again, Thanks! > http://cr.openjdk.java.net/~ewang/8015765/webrev.01/ > > > Eric > On 2013/8/13 21:48, Chris Hegarty wrote: >> This test looks a little bizarre, and certainly racy. What you have >> done should make the test more reliable. >> >> I noticed that the server socket channel is only closed if a socket is >> accepted. I think it should be closed always, regardless of whether a >> socket is accepted or not. Though this is not directly related to your >> changes. >> >> -Chris >> >> On 08/13/2013 12:24 PM, Eric Wang wrote: >>> Hi, >>> >>> Please help to review the fix below for the bug >>> https://jbs.oracle.com/bugs/browse/JDK-8015765. >>> http://cr.openjdk.java.net/~ewang/8015765/webrev.00/ >>> >>> As the test is depended on thread schedule, it may fail >>> intermittently.The fix is to adjust thread priority, and increase thread >>> sleep duration, to make it more stable. >>> >>> Thanks, >>> Eric > From yiming.wang at oracle.com Wed Aug 14 23:45:10 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 15 Aug 2013 14:45:10 +0800 Subject: Review request for test bug 8015765: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java In-Reply-To: <520C5924.1090308@oracle.com> References: <520A1781.3060305@oracle.com> <520A394B.60102@oracle.com> <520C495D.90501@oracle.com> <520C5924.1090308@oracle.com> Message-ID: <520C78F6.50101@oracle.com> Thanks David, Based on your suggestions, I updated the test again, Can you please help to check? Thanks! http://cr.openjdk.java.net/~ewang/8015765/webrev.02/ Eric On 2013/8/15 12:29, David Holmes wrote: > Eric, > > Glad to hear Thread priority changes are gone :) (Just forget Thread > priority even exists - it is meaningless.) > > Minor style nit: > > 82 try (ServerSocketChannel ssc = > ServerSocketChannel.open(); ServerSocket sso = ssc.socket();) { > > Use a line per declaration. > > I don't know what the key aspects of this test are but I suspect that > "clientStarted" really needs to indicate more than the fact the thread > has started execution of its run() method - ie it should come as close > as possible to the action that the main part of the test depends upon. > > David > > > > On 15/08/2013 1:22 PM, Eric Wang wrote: >> Hi Chris & Alan, >> >> Thanks for the review, I have updated the code based on your >> suggestions. Please help to review again, Thanks! >> http://cr.openjdk.java.net/~ewang/8015765/webrev.01/ >> >> >> Eric >> On 2013/8/13 21:48, Chris Hegarty wrote: >>> This test looks a little bizarre, and certainly racy. What you have >>> done should make the test more reliable. >>> >>> I noticed that the server socket channel is only closed if a socket is >>> accepted. I think it should be closed always, regardless of whether a >>> socket is accepted or not. Though this is not directly related to your >>> changes. >>> >>> -Chris >>> >>> On 08/13/2013 12:24 PM, Eric Wang wrote: >>>> Hi, >>>> >>>> Please help to review the fix below for the bug >>>> https://jbs.oracle.com/bugs/browse/JDK-8015765. >>>> http://cr.openjdk.java.net/~ewang/8015765/webrev.00/ >>>> >>>> As the test is depended on thread schedule, it may fail >>>> intermittently.The fix is to adjust thread priority, and increase >>>> thread >>>> sleep duration, to make it more stable. >>>> >>>> Thanks, >>>> Eric >> From david.holmes at oracle.com Thu Aug 15 03:07:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Aug 2013 20:07:34 +1000 Subject: Review request for test bug 8015765: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java In-Reply-To: <520C78F6.50101@oracle.com> References: <520A1781.3060305@oracle.com> <520A394B.60102@oracle.com> <520C495D.90501@oracle.com> <520C5924.1090308@oracle.com> <520C78F6.50101@oracle.com> Message-ID: <520CA866.2040007@oracle.com> On 15/08/2013 4:45 PM, Eric Wang wrote: > Thanks David, Based on your suggestions, I updated the test again, Can > you please help to check? Thanks! > http://cr.openjdk.java.net/~ewang/8015765/webrev.02/ > You don't need two try-blocks here: 82 try (ServerSocketChannel ssc = ServerSocketChannel.open()) { 83 try (ServerSocket sso = ssc.socket()) { Just try (ServerSocketChannel ssc = ServerSocketChannel.open()); ServerSocket sso = ssc.socket()) { The clientStarted change seems reasonable - but as I said I don't know the details of the socket code and the test. David ----- > Eric > On 2013/8/15 12:29, David Holmes wrote: >> Eric, >> >> Glad to hear Thread priority changes are gone :) (Just forget Thread >> priority even exists - it is meaningless.) >> >> Minor style nit: >> >> 82 try (ServerSocketChannel ssc = >> ServerSocketChannel.open(); ServerSocket sso = ssc.socket();) { >> >> Use a line per declaration. >> >> I don't know what the key aspects of this test are but I suspect that >> "clientStarted" really needs to indicate more than the fact the thread >> has started execution of its run() method - ie it should come as close >> as possible to the action that the main part of the test depends upon. >> >> David >> >> >> >> On 15/08/2013 1:22 PM, Eric Wang wrote: >>> Hi Chris & Alan, >>> >>> Thanks for the review, I have updated the code based on your >>> suggestions. Please help to review again, Thanks! >>> http://cr.openjdk.java.net/~ewang/8015765/webrev.01/ >>> >>> >>> Eric >>> On 2013/8/13 21:48, Chris Hegarty wrote: >>>> This test looks a little bizarre, and certainly racy. What you have >>>> done should make the test more reliable. >>>> >>>> I noticed that the server socket channel is only closed if a socket is >>>> accepted. I think it should be closed always, regardless of whether a >>>> socket is accepted or not. Though this is not directly related to your >>>> changes. >>>> >>>> -Chris >>>> >>>> On 08/13/2013 12:24 PM, Eric Wang wrote: >>>>> Hi, >>>>> >>>>> Please help to review the fix below for the bug >>>>> https://jbs.oracle.com/bugs/browse/JDK-8015765. >>>>> http://cr.openjdk.java.net/~ewang/8015765/webrev.00/ >>>>> >>>>> As the test is depended on thread schedule, it may fail >>>>> intermittently.The fix is to adjust thread priority, and increase >>>>> thread >>>>> sleep duration, to make it more stable. >>>>> >>>>> Thanks, >>>>> Eric >>> > From Alan.Bateman at oracle.com Thu Aug 15 03:08:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Aug 2013 11:08:20 +0100 Subject: Review request for test bug 8015765: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java In-Reply-To: <520C78F6.50101@oracle.com> References: <520A1781.3060305@oracle.com> <520A394B.60102@oracle.com> <520C495D.90501@oracle.com> <520C5924.1090308@oracle.com> <520C78F6.50101@oracle.com> Message-ID: <520CA894.2090103@oracle.com> On 15/08/2013 07:45, Eric Wang wrote: > Thanks David, Based on your suggestions, I updated the test again, Can > you please help to check? Thanks! > http://cr.openjdk.java.net/~ewang/8015765/webrev.02/ > > > Eric This looks much better, I guess I would probably have used while rather than do-while but what you have is fine. If we are done then I can sponsor this for you. -Alan. From yiming.wang at oracle.com Thu Aug 15 03:40:49 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 15 Aug 2013 18:40:49 +0800 Subject: Review request for test bug 8015765: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java In-Reply-To: <520CA866.2040007@oracle.com> References: <520A1781.3060305@oracle.com> <520A394B.60102@oracle.com> <520C495D.90501@oracle.com> <520C5924.1090308@oracle.com> <520C78F6.50101@oracle.com> <520CA866.2040007@oracle.com> Message-ID: <520CB031.3090907@oracle.com> Thanks David! I misunderstood your meaning of the previous mail, The test has been updated :) Hi Alan, I'm done with the test, Thank you to be my sponsor, below is the latest changes: http://cr.openjdk.java.net/~ewang/8015765/webrev.03/ Thanks, Eric On 2013/8/15 18:07, David Holmes wrote: > On 15/08/2013 4:45 PM, Eric Wang wrote: >> Thanks David, Based on your suggestions, I updated the test again, Can >> you please help to check? Thanks! >> http://cr.openjdk.java.net/~ewang/8015765/webrev.02/ >> > > You don't need two try-blocks here: > > 82 try (ServerSocketChannel ssc = ServerSocketChannel.open()) { > 83 try (ServerSocket sso = ssc.socket()) { > > Just > > try (ServerSocketChannel ssc = ServerSocketChannel.open()); > ServerSocket sso = ssc.socket()) { > > The clientStarted change seems reasonable - but as I said I don't know > the details of the socket code and the test. > > David > ----- > >> Eric >> On 2013/8/15 12:29, David Holmes wrote: >>> Eric, >>> >>> Glad to hear Thread priority changes are gone :) (Just forget Thread >>> priority even exists - it is meaningless.) >>> >>> Minor style nit: >>> >>> 82 try (ServerSocketChannel ssc = >>> ServerSocketChannel.open(); ServerSocket sso = ssc.socket();) { >>> >>> Use a line per declaration. >>> >>> I don't know what the key aspects of this test are but I suspect that >>> "clientStarted" really needs to indicate more than the fact the thread >>> has started execution of its run() method - ie it should come as close >>> as possible to the action that the main part of the test depends upon. >>> >>> David >>> >>> >>> >>> On 15/08/2013 1:22 PM, Eric Wang wrote: >>>> Hi Chris & Alan, >>>> >>>> Thanks for the review, I have updated the code based on your >>>> suggestions. Please help to review again, Thanks! >>>> http://cr.openjdk.java.net/~ewang/8015765/webrev.01/ >>>> >>>> >>>> Eric >>>> On 2013/8/13 21:48, Chris Hegarty wrote: >>>>> This test looks a little bizarre, and certainly racy. What you have >>>>> done should make the test more reliable. >>>>> >>>>> I noticed that the server socket channel is only closed if a >>>>> socket is >>>>> accepted. I think it should be closed always, regardless of whether a >>>>> socket is accepted or not. Though this is not directly related to >>>>> your >>>>> changes. >>>>> >>>>> -Chris >>>>> >>>>> On 08/13/2013 12:24 PM, Eric Wang wrote: >>>>>> Hi, >>>>>> >>>>>> Please help to review the fix below for the bug >>>>>> https://jbs.oracle.com/bugs/browse/JDK-8015765. >>>>>> http://cr.openjdk.java.net/~ewang/8015765/webrev.00/ >>>>>> >>>>>> As the test is depended on thread schedule, it may fail >>>>>> intermittently.The fix is to adjust thread priority, and increase >>>>>> thread >>>>>> sleep duration, to make it more stable. >>>>>> >>>>>> Thanks, >>>>>> Eric >>>> >> From Alan.Bateman at oracle.com Thu Aug 15 03:52:59 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Aug 2013 11:52:59 +0100 Subject: Review request for test bug 8015765: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java In-Reply-To: <520CB031.3090907@oracle.com> References: <520A1781.3060305@oracle.com> <520A394B.60102@oracle.com> <520C495D.90501@oracle.com> <520C5924.1090308@oracle.com> <520C78F6.50101@oracle.com> <520CA866.2040007@oracle.com> <520CB031.3090907@oracle.com> Message-ID: <520CB30B.40106@oracle.com> On 15/08/2013 11:40, Eric Wang wrote: > Thanks David! I misunderstood your meaning of the previous mail, The > test has been updated :) > > Hi Alan, > I'm done with the test, Thank you to be my sponsor, below is the > latest changes: > http://cr.openjdk.java.net/~ewang/8015765/webrev.03/ > > I'm happy with this, I'll push it for you today. I assume you'll reply soon on the other test (AdaptDatagramSocket.java) as I don't think I fully understood the issue (or the fix). -Alan. From yiming.wang at oracle.com Thu Aug 22 03:18:55 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 22 Aug 2013 18:18:55 +0800 Subject: [PATCH] Review request for bug 8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8) Message-ID: <5215E58F.3080109@oracle.com> Hi, Please review the fix for bug https://bugs.openjdk.java.net/browse/JDK-8023139, the test fails due to interference of McAfee. As McAfee cannot be configured due to company policy, the fix is to workaround the interference by checking the modify event of the expected file can always be found in the event queue. http://cr.openjdk.java.net/~ewang/8023139/webrev.00/ Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130822/c286653c/attachment.html From Alan.Bateman at oracle.com Fri Aug 23 05:32:35 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Aug 2013 13:32:35 +0100 Subject: [PATCH] Review request for bug 8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8) In-Reply-To: <5215E58F.3080109@oracle.com> References: <5215E58F.3080109@oracle.com> Message-ID: <52175663.8090606@oracle.com> On 22/08/2013 11:18, Eric Wang wrote: > Hi, > > Please review the fix for bug > https://bugs.openjdk.java.net/browse/JDK-8023139, the test fails due > to interference of McAfee. > As McAfee cannot be configured due to company policy, the fix is to > workaround the interference by checking the modify event of the > expected file can always be found in the event queue. > > http://cr.openjdk.java.net/~ewang/8023139/webrev.00/ > Thanks for looking into this one, these interference issues are a royal pain. Your approaching to filtering is okay but it drops the check that the event is a modify event. I've taken your patch and massaged it a bit to this: http://cr.openjdk.java.net/~alanb/8023139/webrev/ If you are okay with this and I can sponsor the patch and get it pushed for you. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130823/35c033ec/attachment.html From yiming.wang at oracle.com Sun Aug 25 19:33:50 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Mon, 26 Aug 2013 10:33:50 +0800 Subject: [PATCH] Review request for bug 8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8) In-Reply-To: <52175663.8090606@oracle.com> References: <5215E58F.3080109@oracle.com> <52175663.8090606@oracle.com> Message-ID: <521ABE8E.60408@oracle.com> Hi Alan, Thanks to be my sponsor, I'm OK with your updates. Regards, Eric On 2013/8/23 20:32, Alan Bateman wrote: > On 22/08/2013 11:18, Eric Wang wrote: >> Hi, >> >> Please review the fix for bug >> https://bugs.openjdk.java.net/browse/JDK-8023139, the test fails due >> to interference of McAfee. >> As McAfee cannot be configured due to company policy, the fix is to >> workaround the interference by checking the modify event of the >> expected file can always be found in the event queue. >> >> http://cr.openjdk.java.net/~ewang/8023139/webrev.00/ >> > Thanks for looking into this one, these interference issues are a > royal pain. > > Your approaching to filtering is okay but it drops the check that the > event is a modify event. I've taken your patch and massaged it a bit > to this: > > http://cr.openjdk.java.net/~alanb/8023139/webrev/ > > If you are okay with this and I can sponsor the patch and get it > pushed for you. > > -Alan. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130826/040bc834/attachment.html From Alan.Bateman at oracle.com Mon Aug 26 01:54:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Aug 2013 09:54:06 +0100 Subject: 8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil Message-ID: <521B17AE.6080607@oracle.com> Jeremy Manson recently reported a sighting of a deadlock at startup in the static initializers that are involved in loading libnio/equivalent [1]. Digging through the JDK 1.4/1.5 era history then it seems there were other issues that lead to the current implementation. Looking at now and since sun.nio.ch.Util doesn't have any native methods then the simplest thing to do (but not the only solution) is to move the loading of the native libraries to IOUtil. That eliminates the need for the additional locking. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8022594/webrev/ The patch does not include a test as this is a deadlock at startup that just isn't easy to reproduce (at least not on the systems that I tried). -Alan [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019630.html From Alan.Bateman at oracle.com Mon Aug 26 02:42:42 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Aug 2013 10:42:42 +0100 Subject: [PATCH] Review request for bug 8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8) In-Reply-To: <521ABE8E.60408@oracle.com> References: <5215E58F.3080109@oracle.com> <52175663.8090606@oracle.com> <521ABE8E.60408@oracle.com> Message-ID: <521B2312.6070000@oracle.com> On 26/08/2013 03:33, Eric Wang wrote: > Hi Alan, > > Thanks to be my sponsor, I'm OK with your updates. Thanks, I've pushed the change. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130826/dfa4fcb0/attachment.html From chris.hegarty at oracle.com Wed Aug 28 05:48:33 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 28 Aug 2013 13:48:33 +0100 Subject: 8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil In-Reply-To: <521B17AE.6080607@oracle.com> References: <521B17AE.6080607@oracle.com> Message-ID: <521DF1A1.1050804@oracle.com> The changes look good to me Alan. I verified that the removal (IO)Util.load should be fine where you have done it, as those classes don't have native methods. Trivially, I don't think SctpMultiChannelImpl or SctpServerChannelImpl need to call IOUtil.load ( or load libsctp ) as they don't have any native methods, but I appreciate you fixing these and understand if you don't want to change them as part of this changeset. -Chris. On 26/08/2013 09:54, Alan Bateman wrote: > > Jeremy Manson recently reported a sighting of a deadlock at startup in > the static initializers that are involved in loading libnio/equivalent [1]. > > Digging through the JDK 1.4/1.5 era history then it seems there were > other issues that lead to the current implementation. Looking at now and > since sun.nio.ch.Util doesn't have any native methods then the simplest > thing to do (but not the only solution) is to move the loading of the > native libraries to IOUtil. That eliminates the need for the additional > locking. > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8022594/webrev/ > > The patch does not include a test as this is a deadlock at startup that > just isn't easy to reproduce (at least not on the systems that I tried). > > -Alan > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019630.html > From Alan.Bateman at oracle.com Wed Aug 28 07:51:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Aug 2013 15:51:01 +0100 Subject: 8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil In-Reply-To: <521DF1A1.1050804@oracle.com> References: <521B17AE.6080607@oracle.com> <521DF1A1.1050804@oracle.com> Message-ID: <521E0E55.3090206@oracle.com> On 28/08/2013 13:48, Chris Hegarty wrote: > The changes look good to me Alan. > > I verified that the removal (IO)Util.load should be fine where you > have done it, as those classes don't have native methods. > > Trivially, I don't think SctpMultiChannelImpl or SctpServerChannelImpl > need to call IOUtil.load ( or load libsctp ) as they don't have any > native methods, but I appreciate you fixing these and understand if > you don't want to change them as part of this changeset. > > -Chris. > SctpMultiChannelImpl and SctpServerChannelImpl load libsctp (which is linked to libnio and libnet) so it's probably best if we do the initialization consistently to avoid other potential issues. -Alan. From david.holmes at oracle.com Fri Aug 30 01:03:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Aug 2013 18:03:18 +1000 Subject: FileStore equality ? Message-ID: <522051C6.6070702@oracle.com> Hi, I have the following failure in test/java/nio/file/FileStore/Basic.java / (rootfs) (name=rootfs type=rootfs) / (/dev/root) (name=/dev/root type=ext3) ----------System.err:(15/760)---------- java.lang.RuntimeException: Assertion failed at Basic.assertTrue(Basic.java:51) at Basic.doTests(Basic.java:123) at Basic.main(Basic.java:43) The two filestores are comparing equal when the test expects otherwise. Does this look like a test bug or a code issue? This is in 7u. Please cc me directly as I don't mail from this list. Thanks, David From Alan.Bateman at oracle.com Fri Aug 30 01:52:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 Aug 2013 09:52:58 +0100 Subject: FileStore equality ? In-Reply-To: <522051C6.6070702@oracle.com> References: <522051C6.6070702@oracle.com> Message-ID: <52205D6A.9020103@oracle.com> On 30/08/2013 09:03, David Holmes wrote: > Hi, > > I have the following failure in > > test/java/nio/file/FileStore/Basic.java > > / (rootfs) (name=rootfs type=rootfs) > / (/dev/root) (name=/dev/root type=ext3) > ----------System.err:(15/760)---------- > java.lang.RuntimeException: Assertion failed > at Basic.assertTrue(Basic.java:51) > at Basic.doTests(Basic.java:123) > at Basic.main(Basic.java:43) > > > The two filestores are comparing equal when the test expects > otherwise. Does this look like a test bug or a code issue? We have a long standing issue to resolve with how to overlaid mounts. It hasn't come up for a while so I'm curious which distribution/version this is? -Alan From jeremymanson at google.com Wed Aug 7 09:56:35 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 07 Aug 2013 16:56:35 -0000 Subject: Deadlock in clinit for sun.nio.ch.Util/IOUtil In-Reply-To: <5201D94D.3000407@oracle.com> References: <5201D94D.3000407@oracle.com> Message-ID: Thanks, Alan. Do please ping back when you've created the bug (I'm not on nio-dev), because I'd like to track it (so we can remove our workaround when the time comes). Jeremy On Tue, Aug 6, 2013 at 10:21 PM, Alan Bateman wrote: > On 06/08/2013 15:21, Jeremy Manson wrote: > >> : >> >> >> We can eagerly do class init as a workaround, but that seems less than >> ideal. It looks easy enough to fix - just move the stuff in Util.load() >> into IOUtil somewhere, and don't call back to Util from IOUtil.. >> But I'll defer to the experts. >> >> Thanks for the mail, I'll create a bug for this. From an initial look > then moving it to IOUtil should resolve this as Util doesn't define any > native methods and so doesn't care if the native library has been loaded. > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130807/0cd0c6fd/attachment.html