From paul.sandoz at oracle.com Wed Jul 16 12:58:25 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Jul 2014 14:58:25 +0200 Subject: Covariant overrides on the Buffer Hierarchy redux Message-ID: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> Hi, There was discussion here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026458.html https://bugs.openjdk.java.net/browse/JDK-4774077 http://cr.openjdk.java.net/~rwarburton/buffer-overrides-1/ The patch looks good. I have just one comment: can you check the tests to see if there are any redundant casts? After that i will run a JPRT test and then will push for you. Thanks, Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Alan.Bateman at oracle.com Wed Jul 16 13:42:49 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jul 2014 14:42:49 +0100 Subject: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> Message-ID: <53C68159.5050003@oracle.com> On 16/07/2014 13:58, Paul Sandoz wrote: > Hi, > > There was discussion here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026458.html > > https://bugs.openjdk.java.net/browse/JDK-4774077 > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-1/ > > > The patch looks good. > Looks good okay to me too except that @inheritDoc doesn't inherit the runtime exceptions so I assume that @throws will need to be added to ensure that the javadoc is complete. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Thu Jul 17 21:19:58 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 17 Jul 2014 14:19:58 -0700 Subject: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> Message-ID: <20140717141958.734274@eggemoggin.niobe.net> 2014/7/15 22:58 -0700, paul.sandoz at oracle.com: > There was discussion here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026458.html > > https://bugs.openjdk.java.net/browse/JDK-4774077 > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-1/ > > The patch looks good. Agreed! Glad to see this (finally) get done. - Mark From mike.duigou at oracle.com Thu Jul 17 22:05:46 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 17 Jul 2014 15:05:46 -0700 Subject: RFR: 8051057: (s) Optimize StringCharBuffer.toString(int, int) Message-ID: Hello all; While investigating another issue I ran across some code in java.nio.StringCharBuffer.toString(int, int) which might be possible to improve. Currently the implementation calls toString() on the source CharSequence and then uses String.substring to create the desired range. For the current String, StringBuilder and StringBuffer implementations it would be more efficient to first generate the subSequence via CharSequence.subSequence(int, int) and then call toString() on the sub-sequence. For these classes the toString() is actually a NOP as their CharSequence.subSequence(int, int) implementations return a String instance. I looked for other CharSequence implementations and couldn't find any which would preform better with current StringCharBuffer.toString(int, int) implementation. jbsbug: https://bugs.openjdk.java.net/browse/JDK-8051057 webrev: http://cr.openjdk.java.net/~mduigou/JDK-8051057/0/webrev/ Does this seem like a worthwhile improvement for all of the important CharSequence implementations? Mike From Alan.Bateman at oracle.com Fri Jul 18 13:58:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Jul 2014 14:58:44 +0100 Subject: RFR: 8051057: (s) Optimize StringCharBuffer.toString(int, int) In-Reply-To: References: Message-ID: <53C92814.3020103@oracle.com> On 17/07/2014 23:05, Mike Duigou wrote: > Hello all; > > While investigating another issue I ran across some code in java.nio.StringCharBuffer.toString(int, int) which might be possible to improve. Currently the implementation calls toString() on the source CharSequence and then uses String.substring to create the desired range. For the current String, StringBuilder and StringBuffer implementations it would be more efficient to first generate the subSequence via CharSequence.subSequence(int, int) and then call toString() on the sub-sequence. For these classes the toString() is actually a NOP as their CharSequence.subSequence(int, int) implementations return a String instance. > > I looked for other CharSequence implementations and couldn't find any which would preform better with current StringCharBuffer.toString(int, int) implementation. > > jbsbug: https://bugs.openjdk.java.net/browse/JDK-8051057 > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8051057/0/webrev/ > > Does this seem like a worthwhile improvement for all of the important CharSequence implementations? > I think this look okay and should be equivalent. Make sure to run the :jdk_nio tests as StringCharBuffer has a history of biting fingers. -Alan. From Alan.Bateman at oracle.com Thu Jul 31 04:49:03 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Jul 2014 05:49:03 +0100 Subject: Fwd: 8053931: (fc) FileDispatcherImpl.lock0 does not handle ERROR_IO_PENDING [win] In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116566ACB8807@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB418116566ACB8807@DEWDFEMB19C.global.corp.sap> Message-ID: <53D9CABF.8040400@oracle.com> Forwarding Martin's mail, it seems to have got stuck because he was subscribed at the time. Martin - one question about this, CreateFile isn't being opened with FILE_FLAG_OVERLAPPED so I'm curious if this is set in your port. I'm mostly asking because this code hasn't changed much since the original implementation in JDK 1.4 and I'm not aware of any reports of issues. -Alan *From:*Doerr, Martin *Sent:* Mittwoch, 30. Juli 2014 13:08 *To:* 'nio-dev at openjdk.java.net' *Subject:* 8053931: Fix bug in Java_sun_nio_ch_FileDispatcherImpl_lock0 (windows) Hi all, we have seen crashes and unexpected exceptions due to a bug in Java_sun_nio_ch_FileDispatcherImpl_lock0 under windows when running the jck test "api/java_nio/channels/AsynchronousFileChannel/AsynchronousFileChannel.html#tryLock". The exception text states "Overlapped I/O operation is in progress" which is the error returned by the windows API function "LockFileEx". The c code contains the following. Note that LockFileEx works asynchronously in this test. OVERLAPPED o; ... result = LockFileEx(h, flags, 0, lowNumBytes, highNumBytes, &o); ... no check for o afterwards! With this current coding, Java_sun_nio_ch_FileDispatcherImpl_lock0 may return even though I/O is still pending. The asynchronous LockFileEx then modifies the OVERLAPPED o on stack which is no longer valid because the stack frame has gone. According to Microsoft, this is not allowed: -Do not deallocate or modify the OVERLAPPED structure or the data buffer until all asynchronous I/O operations to the file object have been completed. -If you declare your pointer to the OVERLAPPED structure as a local variable, do not exit the local function until all asynchronous I/O operations to the file object have been completed. If the local function is exited prematurely, the OVERLAPPED structure will go out of scope and it will be inaccessible to any ReadFile or WriteFile functions it encounters outside of that function. (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365683%28v=vs.85%29.aspx) The LockFileEx function is described here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365203%28v=vs.85%29.aspx A possible way to fix this problem, is to check for ERROR_IO_PENDING and use GetOverlappedResult to wait until the update to o has been completed and we can safely return if the locking has worked or not. See webrev http://cr.openjdk.java.net/~goetz/webrevs/8053931-tryLock/webrev-01/ We know that this defeats the purpose of being asynchronous to some extend, because GetOverlappedResult waits for the I/O in case of ERROR_IO_PENDING. Do we need to optimize this case and return to java to do something else? If yes, it requires to change the tryLock mechanism because the OVERLAPPED structure needs to get passed to someone who checks and frees it later. Please note that I'll be out from 10/01 to 10/11. I just want to report this problem before I leave. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Thu Jul 31 08:08:59 2014 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 31 Jul 2014 08:08:59 +0000 Subject: 8053931: (fc) FileDispatcherImpl.lock0 does not handle ERROR_IO_PENDING [win] In-Reply-To: <53D9CABF.8040400@oracle.com> References: <7C9B87B351A4BA4AA9EC95BB418116566ACB8807@DEWDFEMB19C.global.corp.sap> <53D9CABF.8040400@oracle.com> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116566ACB8937@DEWDFEMB19C.global.corp.sap> Hi Alan, I've tried the official Oracle JVM jdk1.8.0_11 and it shows the same problem: C:\temp>C:\Java\jdk1.8.0_11\bin\java -Djava.compiler=none -verify -classpath \\hs0131\hs0131.a\sapjvm_dev\jck\jck8\JCK-runtime-8\classes -Djava.security.policy=\\hs0131\hs0131.a\sapjvm_dev\jck\jck8\JCK-runtime-8\lib\jck.policy javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests -TestURL file:////hs0131/hs0131.a/sapjvm_dev/jck/jck8/JCK-runtime-8/tests/api/java_nio/channels/AsynchronousFileChannel/AsynchronousFileChannel.html#tryLock -TestWorkDirURL file:/X:/certification/JCK-runtime-8/workdir/api/java_nio/channels/AsynchronousFileChannel/ In a first attempt, the JVM crashed with a broken stack (probably because the OVERLAPPED structure was modified after the frame was gone and something else was there). In a second attempt, some subtests failed with the exception: FAILED: Unexpected java.io.IOException: Overlapped I/O operation is in progress (complete output below) My machine is a desktop PC with a Core i7 870 (2.93 GHz) processor and a classical NTFS hard disk drive. Shouldn't be too special. Maybe the windows version plays a role (Microsoft Windows [Version 6.2.9200]). We have tried the fix from http://cr.openjdk.java.net/~goetz/webrevs/8053931-tryLock/webrev-01/ with our JVM and it has solved the problem. Please note that I'll be out for the next 11 days. Best regards, Martin Complete output: tryLock01_04: Passed. OKAY tryLock02_01: Failed. FAILED tryLock01_02: Passed. OKAY tryLock01_05: Passed. OKAY tryLock01_03: Failed. FAILED tryLock01_09: Failed. FAILED tryLock01_07: Passed. OKAY tryLock01_08: Passed. OKAY tryLock01_06: Passed. OKAY tryLock02_02: Passed. OKAY tryLock01_01: Passed. OKAY ==== tryLock01_04 ==== IllegalArgumentException was thrown asexpected ==== tryLock02_01 ==== FAILED: Unexpected java.io.IOException: Overlapped I/O operation is in progress java.io.IOException: Overlapped I/O operation is in progress at sun.nio.ch.FileDispatcherImpl.lock0(Native Method) at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:102) at sun.nio.ch.WindowsAsynchronousFileChannelImpl.tryLock(WindowsAsynchronousFileChannelImpl.java:359) at java.nio.channels.AsynchronousFileChannel.tryLock(AsynchronousFileChannel.java:640) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests$10.runTest(TryLockTests.java:399) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestSafely(Nio2TestCase.java:385) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single$1.run(Nio2TestCase.java:349) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithTCKSM(SecurityTestRunner.java:279) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithPermissions(SecurityTestRunner.java:235) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithPerms(Nio2TestCase.java:354) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithAllPermsDenied(Nio2TestCase.java:270) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.tryLock02_01(TryLockTests.java:406) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at javasoft.sqe.javatest.lib.MultiTest.invokeTestCase(MultiTest.java:405) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:194) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:126) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.main(TryLockTests.java:53) ==== tryLock01_02 ==== NonReadableChannelException was thrown as expected ==== tryLock01_05 ==== IllegalArgumentException was thrown asexpected ==== tryLock01_03 ==== FAILED: Unexpected java.io.IOException: Overlapped I/O operation is in progress java.io.IOException: Overlapped I/O operation is in progress at sun.nio.ch.FileDispatcherImpl.lock0(Native Method) at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:102) at sun.nio.ch.WindowsAsynchronousFileChannelImpl.tryLock(WindowsAsynchronousFileChannelImpl.java:359) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests$3.runTest(TryLockTests.java:154) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestSafely(Nio2TestCase.java:385) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single$1.run(Nio2TestCase.java:349) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithTCKSM(SecurityTestRunner.java:279) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithPermissions(SecurityTestRunner.java:235) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithPerms(Nio2TestCase.java:354) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithAllPermsDenied(Nio2TestCase.java:270) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.tryLock01_03(TryLockTests.java:166) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at javasoft.sqe.javatest.lib.MultiTest.invokeTestCase(MultiTest.java:405) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:194) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:126) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.main(TryLockTests.java:53) ==== tryLock01_09 ==== FAILED: Unexpected java.io.IOException: Overlapped I/O operation is in progress java.io.IOException: Overlapped I/O operation is in progress at sun.nio.ch.FileDispatcherImpl.lock0(Native Method) at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:102) at sun.nio.ch.WindowsAsynchronousFileChannelImpl.tryLock(WindowsAsynchronousFileChannelImpl.java:359) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests$9.runTest(TryLockTests.java:362) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestSafely(Nio2TestCase.java:385) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single$1.run(Nio2TestCase.java:349) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithTCKSM(SecurityTestRunner.java:279) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithPermissions(SecurityTestRunner.java:235) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithPerms(Nio2TestCase.java:354) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithAllPermsDenied(Nio2TestCase.java:270) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.tryLock01_09(TryLockTests.java:374) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at javasoft.sqe.javatest.lib.MultiTest.invokeTestCase(MultiTest.java:405) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:194) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:126) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.main(TryLockTests.java:53) ==== tryLock01_07 ==== ClosedChannelException was thrown as expected ==== tryLock01_08 ==== OverlappingFileLockException was thrown as expected ==== tryLock01_06 ==== IllegalArgumentException was thrown asexpected ==== tryLock02_02 ==== NonWritableChannelException was thrown asexpected ==== tryLock01_01 ==== NonWritableChannelException was thrown as expected STATUS:Failed.test cases: 11; passed: 8; failed: 3; first test case failure: tryLock02_01 From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Donnerstag, 31. Juli 2014 06:49 To: nio-dev Cc: Doerr, Martin Subject: Fwd: 8053931: (fc) FileDispatcherImpl.lock0 does not handle ERROR_IO_PENDING [win] Forwarding Martin's mail, it seems to have got stuck because he was subscribed at the time. Martin - one question about this, CreateFile isn't being opened with FILE_FLAG_OVERLAPPED so I'm curious if this is set in your port. I'm mostly asking because this code hasn't changed much since the original implementation in JDK 1.4 and I'm not aware of any reports of issues. -Alan From: Doerr, Martin Sent: Mittwoch, 30. Juli 2014 13:08 To: 'nio-dev at openjdk.java.net' Subject: 8053931: Fix bug in Java_sun_nio_ch_FileDispatcherImpl_lock0 (windows) Hi all, we have seen crashes and unexpected exceptions due to a bug in Java_sun_nio_ch_FileDispatcherImpl_lock0 under windows when running the jck test "api/java_nio/channels/AsynchronousFileChannel/AsynchronousFileChannel.html#tryLock". The exception text states "Overlapped I/O operation is in progress" which is the error returned by the windows API function "LockFileEx". The c code contains the following. Note that LockFileEx works asynchronously in this test. OVERLAPPED o; ... result = LockFileEx(h, flags, 0, lowNumBytes, highNumBytes, &o); ... no check for o afterwards! With this current coding, Java_sun_nio_ch_FileDispatcherImpl_lock0 may return even though I/O is still pending. The asynchronous LockFileEx then modifies the OVERLAPPED o on stack which is no longer valid because the stack frame has gone. According to Microsoft, this is not allowed: -Do not deallocate or modify the OVERLAPPED structure or the data buffer until all asynchronous I/O operations to the file object have been completed. -If you declare your pointer to the OVERLAPPED structure as a local variable, do not exit the local function until all asynchronous I/O operations to the file object have been completed. If the local function is exited prematurely, the OVERLAPPED structure will go out of scope and it will be inaccessible to any ReadFile or WriteFile functions it encounters outside of that function. (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365683%28v=vs.85%29.aspx) The LockFileEx function is described here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365203%28v=vs.85%29.aspx A possible way to fix this problem, is to check for ERROR_IO_PENDING and use GetOverlappedResult to wait until the update to o has been completed and we can safely return if the locking has worked or not. See webrev http://cr.openjdk.java.net/~goetz/webrevs/8053931-tryLock/webrev-01/ We know that this defeats the purpose of being asynchronous to some extend, because GetOverlappedResult waits for the I/O in case of ERROR_IO_PENDING. Do we need to optimize this case and return to java to do something else? If yes, it requires to change the tryLock mechanism because the OVERLAPPED structure needs to get passed to someone who checks and frees it later. Please note that I'll be out from 10/01 to 10/11. I just want to report this problem before I leave. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Thu Jul 31 09:28:37 2014 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 31 Jul 2014 09:28:37 +0000 Subject: 8053931: (fc) FileDispatcherImpl.lock0 does not handle ERROR_IO_PENDING [win] In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116566ACB8937@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB418116566ACB8807@DEWDFEMB19C.global.corp.sap> <53D9CABF.8040400@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116566ACB8937@DEWDFEMB19C.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116566ACB8956@DEWDFEMB19C.global.corp.sap> Hi again, I can also reproduce it on a laptop with the Oracle VM on Windows 7 (Microsoft Windows [Version 6.1.7601]). # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006ff41034, pid=16824, tid=10756 # # JRE version: Java(TM) SE Runtime Environment (8.0_11-b12) (build 1.8.0_11-b12) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.11-b03 interpreted mode windows-amd64 compressed oops) In another attempt, the test has failed the same way as on my Windows 8 system (see below). Maybe the network infrastructure plays a role. The workdir is on a network drive. Best regards, Martin From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Donnerstag, 31. Juli 2014 10:09 To: Alan Bateman; nio-dev Subject: RE: 8053931: (fc) FileDispatcherImpl.lock0 does not handle ERROR_IO_PENDING [win] Hi Alan, I've tried the official Oracle JVM jdk1.8.0_11 and it shows the same problem: C:\temp>C:\Java\jdk1.8.0_11\bin\java -Djava.compiler=none -verify -classpath \\hs0131\hs0131.a\sapjvm_dev\jck\jck8\JCK-runtime-8\classes -Djava.security.policy=\\hs0131\hs0131.a\sapjvm_dev\jck\jck8\JCK-runtime-8\lib\jck.policy javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests -TestURL file:////hs0131/hs0131.a/sapjvm_dev/jck/jck8/JCK-runtime-8/tests/api/java_nio/channels/AsynchronousFileChannel/AsynchronousFileChannel.html#tryLock -TestWorkDirURL file:/X:/certification/JCK-runtime-8/workdir/api/java_nio/channels/AsynchronousFileChannel/ In a first attempt, the JVM crashed with a broken stack (probably because the OVERLAPPED structure was modified after the frame was gone and something else was there). In a second attempt, some subtests failed with the exception: FAILED: Unexpected java.io.IOException: Overlapped I/O operation is in progress (complete output below) My machine is a desktop PC with a Core i7 870 (2.93 GHz) processor and a classical NTFS hard disk drive. Shouldn't be too special. Maybe the windows version plays a role (Microsoft Windows [Version 6.2.9200]). We have tried the fix from http://cr.openjdk.java.net/~goetz/webrevs/8053931-tryLock/webrev-01/ with our JVM and it has solved the problem. Please note that I'll be out for the next 11 days. Best regards, Martin Complete output: tryLock01_04: Passed. OKAY tryLock02_01: Failed. FAILED tryLock01_02: Passed. OKAY tryLock01_05: Passed. OKAY tryLock01_03: Failed. FAILED tryLock01_09: Failed. FAILED tryLock01_07: Passed. OKAY tryLock01_08: Passed. OKAY tryLock01_06: Passed. OKAY tryLock02_02: Passed. OKAY tryLock01_01: Passed. OKAY ==== tryLock01_04 ==== IllegalArgumentException was thrown asexpected ==== tryLock02_01 ==== FAILED: Unexpected java.io.IOException: Overlapped I/O operation is in progress java.io.IOException: Overlapped I/O operation is in progress at sun.nio.ch.FileDispatcherImpl.lock0(Native Method) at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:102) at sun.nio.ch.WindowsAsynchronousFileChannelImpl.tryLock(WindowsAsynchronousFileChannelImpl.java:359) at java.nio.channels.AsynchronousFileChannel.tryLock(AsynchronousFileChannel.java:640) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests$10.runTest(TryLockTests.java:399) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestSafely(Nio2TestCase.java:385) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single$1.run(Nio2TestCase.java:349) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithTCKSM(SecurityTestRunner.java:279) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithPermissions(SecurityTestRunner.java:235) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithPerms(Nio2TestCase.java:354) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithAllPermsDenied(Nio2TestCase.java:270) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.tryLock02_01(TryLockTests.java:406) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at javasoft.sqe.javatest.lib.MultiTest.invokeTestCase(MultiTest.java:405) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:194) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:126) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.main(TryLockTests.java:53) ==== tryLock01_02 ==== NonReadableChannelException was thrown as expected ==== tryLock01_05 ==== IllegalArgumentException was thrown asexpected ==== tryLock01_03 ==== FAILED: Unexpected java.io.IOException: Overlapped I/O operation is in progress java.io.IOException: Overlapped I/O operation is in progress at sun.nio.ch.FileDispatcherImpl.lock0(Native Method) at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:102) at sun.nio.ch.WindowsAsynchronousFileChannelImpl.tryLock(WindowsAsynchronousFileChannelImpl.java:359) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests$3.runTest(TryLockTests.java:154) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestSafely(Nio2TestCase.java:385) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single$1.run(Nio2TestCase.java:349) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithTCKSM(SecurityTestRunner.java:279) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithPermissions(SecurityTestRunner.java:235) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithPerms(Nio2TestCase.java:354) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithAllPermsDenied(Nio2TestCase.java:270) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.tryLock01_03(TryLockTests.java:166) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at javasoft.sqe.javatest.lib.MultiTest.invokeTestCase(MultiTest.java:405) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:194) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:126) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.main(TryLockTests.java:53) ==== tryLock01_09 ==== FAILED: Unexpected java.io.IOException: Overlapped I/O operation is in progress java.io.IOException: Overlapped I/O operation is in progress at sun.nio.ch.FileDispatcherImpl.lock0(Native Method) at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:102) at sun.nio.ch.WindowsAsynchronousFileChannelImpl.tryLock(WindowsAsynchronousFileChannelImpl.java:359) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests$9.runTest(TryLockTests.java:362) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestSafely(Nio2TestCase.java:385) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single$1.run(Nio2TestCase.java:349) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithTCKSM(SecurityTestRunner.java:279) at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithPermissions(SecurityTestRunner.java:235) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithPerms(Nio2TestCase.java:354) at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithAllPermsDenied(Nio2TestCase.java:270) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.tryLock01_09(TryLockTests.java:374) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at javasoft.sqe.javatest.lib.MultiTest.invokeTestCase(MultiTest.java:405) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:194) at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:126) at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.main(TryLockTests.java:53) ==== tryLock01_07 ==== ClosedChannelException was thrown as expected ==== tryLock01_08 ==== OverlappingFileLockException was thrown as expected ==== tryLock01_06 ==== IllegalArgumentException was thrown asexpected ==== tryLock02_02 ==== NonWritableChannelException was thrown asexpected ==== tryLock01_01 ==== NonWritableChannelException was thrown as expected STATUS:Failed.test cases: 11; passed: 8; failed: 3; first test case failure: tryLock02_01 From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Donnerstag, 31. Juli 2014 06:49 To: nio-dev Cc: Doerr, Martin Subject: Fwd: 8053931: (fc) FileDispatcherImpl.lock0 does not handle ERROR_IO_PENDING [win] Forwarding Martin's mail, it seems to have got stuck because he was subscribed at the time. Martin - one question about this, CreateFile isn't being opened with FILE_FLAG_OVERLAPPED so I'm curious if this is set in your port. I'm mostly asking because this code hasn't changed much since the original implementation in JDK 1.4 and I'm not aware of any reports of issues. -Alan From: Doerr, Martin Sent: Mittwoch, 30. Juli 2014 13:08 To: 'nio-dev at openjdk.java.net' Subject: 8053931: Fix bug in Java_sun_nio_ch_FileDispatcherImpl_lock0 (windows) Hi all, we have seen crashes and unexpected exceptions due to a bug in Java_sun_nio_ch_FileDispatcherImpl_lock0 under windows when running the jck test "api/java_nio/channels/AsynchronousFileChannel/AsynchronousFileChannel.html#tryLock". The exception text states "Overlapped I/O operation is in progress" which is the error returned by the windows API function "LockFileEx". The c code contains the following. Note that LockFileEx works asynchronously in this test. OVERLAPPED o; ... result = LockFileEx(h, flags, 0, lowNumBytes, highNumBytes, &o); ... no check for o afterwards! With this current coding, Java_sun_nio_ch_FileDispatcherImpl_lock0 may return even though I/O is still pending. The asynchronous LockFileEx then modifies the OVERLAPPED o on stack which is no longer valid because the stack frame has gone. According to Microsoft, this is not allowed: -Do not deallocate or modify the OVERLAPPED structure or the data buffer until all asynchronous I/O operations to the file object have been completed. -If you declare your pointer to the OVERLAPPED structure as a local variable, do not exit the local function until all asynchronous I/O operations to the file object have been completed. If the local function is exited prematurely, the OVERLAPPED structure will go out of scope and it will be inaccessible to any ReadFile or WriteFile functions it encounters outside of that function. (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365683%28v=vs.85%29.aspx) The LockFileEx function is described here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365203%28v=vs.85%29.aspx A possible way to fix this problem, is to check for ERROR_IO_PENDING and use GetOverlappedResult to wait until the update to o has been completed and we can safely return if the locking has worked or not. See webrev http://cr.openjdk.java.net/~goetz/webrevs/8053931-tryLock/webrev-01/ We know that this defeats the purpose of being asynchronous to some extend, because GetOverlappedResult waits for the I/O in case of ERROR_IO_PENDING. Do we need to optimize this case and return to java to do something else? If yes, it requires to change the tryLock mechanism because the OVERLAPPED structure needs to get passed to someone who checks and frees it later. Please note that I'll be out from 10/01 to 10/11. I just want to report this problem before I leave. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: