From christoph.langer at sap.com Thu Sep 1 07:28:08 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 1 Sep 2016 07:28:08 +0000 Subject: JDK 9 RFR of 8165000: Selector.select(timeout) throws IOException when timeout is a large long In-Reply-To: <2EB7AC83-5376-44F8-8F21-CFDBE90D4070@oracle.com> References: <2EB7AC83-5376-44F8-8F21-CFDBE90D4070@oracle.com> Message-ID: <407d3e06d83c4ee0b010b7b51e789ef3@DEWDFE13DE11.global.corp.sap> Hi Brian, I'm wondering, if we knew that the maximum accepted value for timeout is 0x7fffffff, then we should probably cap the timeout before calling kevent? But other than that, I also don't find any documentation about the maximum accepted timeout or why it obviously needs to be 32bit int max. That would be a question for the Apple guys, I guess. Best regards Christoph > -----Original Message----- > From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Brian > Burkhalter > Sent: Mittwoch, 31. August 2016 22:49 > To: nio-dev > Subject: JDK 9 RFR of 8165000: Selector.select(timeout) throws IOException > when timeout is a large long > > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8165000 > Patch: http://cr.openjdk.java.net/~bpb/8165000/webrev.00/ > > For some unknown reason Selector.open().select(timeout) fails with an > IOException due to an EINVAL error in kevent() [1] when timeout >= > 100000001000L. This was reported on Mac OS 10.11.6 and verified on 10.9.5. It > occurs in both the most recent JDK 8 build and in the JDK 9 EA build. As noted in > a comment on the issue, there are several ways to address this of which the > above patch is one. I am not sure it is the correct path so any comments are > welcome. It would be nice to know for example why kevent() apparently has a > limit on the timeout size and whether this is documented anywhere. I have not > located any such information. > > Thanks, > > Brian > > [1] > https://developer.apple.com/library/ios/documentation/System/Conceptual/M > anPages_iPhoneOS/man2/kevent.2.html From Alan.Bateman at oracle.com Thu Sep 1 10:54:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Sep 2016 11:54:38 +0100 Subject: JDK 9 RFR of 8165000: Selector.select(timeout) throws IOException when timeout is a large long In-Reply-To: <407d3e06d83c4ee0b010b7b51e789ef3@DEWDFE13DE11.global.corp.sap> References: <2EB7AC83-5376-44F8-8F21-CFDBE90D4070@oracle.com> <407d3e06d83c4ee0b010b7b51e789ef3@DEWDFE13DE11.global.corp.sap> Message-ID: <72ee6bed-5682-d820-e46a-aeecee6706dd@oracle.com> On 01/09/2016 08:28, Langer, Christoph wrote: > Hi Brian, > > I'm wondering, if we knew that the maximum accepted value for timeout is 0x7fffffff, then we should probably cap the timeout before calling kevent? > > I agree, it the time out is clamped then it can be done in KQueueArrayWrapper.poll before kqueue is called. -Alan. From brian.burkhalter at oracle.com Thu Sep 1 15:45:55 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Sep 2016 08:45:55 -0700 Subject: JDK 9 RFR of 8165000: Selector.select(timeout) throws IOException when timeout is a large long In-Reply-To: <72ee6bed-5682-d820-e46a-aeecee6706dd@oracle.com> References: <2EB7AC83-5376-44F8-8F21-CFDBE90D4070@oracle.com> <407d3e06d83c4ee0b010b7b51e789ef3@DEWDFE13DE11.global.corp.sap> <72ee6bed-5682-d820-e46a-aeecee6706dd@oracle.com> Message-ID: On Sep 1, 2016, at 3:54 AM, Alan Bateman wrote: > > > On 01/09/2016 08:28, Langer, Christoph wrote: >> Hi Brian, >> >> I'm wondering, if we knew that the maximum accepted value for timeout is 0x7fffffff, then we should probably cap the timeout before calling kevent? >> >> > I agree, it the time out is clamped then it can be done in KQueueArrayWrapper.poll before kqueue is called. Values much larger than 0x7fffffff in fact *are* accepted which is why I chose this version but I can change it to clamp to 0x7fffffff and remove the kevent() retry. Thanks, Brian From brian.burkhalter at oracle.com Thu Sep 1 15:56:49 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Sep 2016 08:56:49 -0700 Subject: JDK 9 RFR of 8165000: Selector.select(timeout) throws IOException when timeout is a large long In-Reply-To: References: <2EB7AC83-5376-44F8-8F21-CFDBE90D4070@oracle.com> <407d3e06d83c4ee0b010b7b51e789ef3@DEWDFE13DE11.global.corp.sap> <72ee6bed-5682-d820-e46a-aeecee6706dd@oracle.com> Message-ID: On Sep 1, 2016, at 8:45 AM, Brian Burkhalter wrote: > Values much larger than 0x7fffffff in fact *are* accepted which is why I chose this version but I can change it to clamp to 0x7fffffff and remove the kevent() retry. Actually from what testing I did it looks as if timeouts in the range [0x7fffffff, 100000000999L] are accepted but those greater than or equal to 100000001000L are not. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Sep 2 19:22:08 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Sep 2016 12:22:08 -0700 Subject: JDK 9 RFR of 8165000: Selector.select(timeout) throws IOException when timeout is a large long In-Reply-To: References: <2EB7AC83-5376-44F8-8F21-CFDBE90D4070@oracle.com> <407d3e06d83c4ee0b010b7b51e789ef3@DEWDFE13DE11.global.corp.sap> <72ee6bed-5682-d820-e46a-aeecee6706dd@oracle.com>

Message-ID: On Sep 1, 2016, at 8:56 AM, Brian Burkhalter wrote: > On Sep 1, 2016, at 8:45 AM, Brian Burkhalter wrote: > >> Values much larger than 0x7fffffff in fact *are* accepted which is why I chose this version but I can change it to clamp to 0x7fffffff and remove the kevent() retry. > > Actually from what testing I did it looks as if timeouts in the range [0x7fffffff, 100000000999L] are accepted but those greater than or equal to 100000001000L are not. Barring objections to the contrary I am going to modify the patch to simply clamp the timeout to Integer.MAX_VALUE, i.e., the maximum value of a 32-bit signed integer. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Wed Sep 7 21:52:19 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Sep 2016 14:52:19 -0700 Subject: RFR: 8165643: SecureDirectoryStream doesn't work on linux non-x86 Message-ID: Hi Alan and Chris, Here's a bad fix for https://bugs.openjdk.java.net/browse/JDK-8165643 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/SecureDirectoryStream-non-x86/ but probably no one will get around to doing the right fix in JDK-8165620 anytime soon. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Sep 8 08:06:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Sep 2016 09:06:40 +0100 Subject: RFR: 8165643: SecureDirectoryStream doesn't work on linux non-x86 In-Reply-To: References: Message-ID: <2243547c-4b1b-abc2-8be7-de33d812e67c@oracle.com> On 07/09/2016 22:52, Martin Buchholz wrote: > Hi Alan and Chris, > > Here's a bad fix for > https://bugs.openjdk.java.net/browse/JDK-8165643 > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/SecureDirectoryStream-non-x86/ > I wonder if we can remove fstatat64_wrapper completely, the reason this code has this is because the support for this function was patchy at the time (some of the platform/versions that the JDK was supported on didn't have it). If you don't want to go that far then that is okay, I just wonder if you could at least avoid have one for i386 and one for 64-bit. -Alan From martinrb at google.com Thu Sep 8 16:10:44 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 8 Sep 2016 09:10:44 -0700 Subject: RFR: 8165643: SecureDirectoryStream doesn't work on linux non-x86 In-Reply-To: <2243547c-4b1b-abc2-8be7-de33d812e67c@oracle.com> References: <2243547c-4b1b-abc2-8be7-de33d812e67c@oracle.com> Message-ID: On Thu, Sep 8, 2016 at 1:06 AM, Alan Bateman wrote: > On 07/09/2016 22:52, Martin Buchholz wrote: > > Hi Alan and Chris, >> >> Here's a bad fix for >> https://bugs.openjdk.java.net/browse/JDK-8165643 >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/SecureDi >> rectoryStream-non-x86/ > Emartin/webrevs/openjdk9/SecureDirectoryStream-non-x86/> >> > I wonder if we can remove fstatat64_wrapper completely, the reason this > code has this is because the support for this function was patchy at the > time (some of the platform/versions that the JDK was supported on didn't > have it). If you don't want to go that far then that is okay, I just wonder > if you could at least avoid have one for i386 and one for 64-bit. It's straightforward to extend my patch to the __i386 case. It's somewhat less straightforward to add configure tests for all the *at functions here. But I only have access to 64-bit Linux at the moment, so I can't do proper testing. It makes sense for someone at Oracle to make more extensive changes. Feel free to do a friendly takeover of this change. The total amount of work will end up smallest if JDK-8165620 actually gets tackled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Sep 8 18:45:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Sep 2016 19:45:01 +0100 Subject: RFR: 8165643: SecureDirectoryStream doesn't work on linux non-x86 In-Reply-To: References: <2243547c-4b1b-abc2-8be7-de33d812e67c@oracle.com> Message-ID: On 08/09/2016 17:10, Martin Buchholz wrote: > > > On Thu, Sep 8, 2016 at 1:06 AM, Alan Bateman > wrote: > > On 07/09/2016 22:52, Martin Buchholz wrote: > > Hi Alan and Chris, > > Here's a bad fix for > https://bugs.openjdk.java.net/browse/JDK-8165643 > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/SecureDirectoryStream-non-x86/ > > > > > I wonder if we can remove fstatat64_wrapper completely, the reason > this code has this is because the support for this function was > patchy at the time (some of the platform/versions that the JDK was > supported on didn't have it). If you don't want to go that far > then that is okay, I just wonder if you could at least avoid have > one for i386 and one for 64-bit. > > > It's straightforward to extend my patch to the __i386 case. It's > somewhat less straightforward to add configure tests for all the *at > functions here. But I only have access to 64-bit Linux at the moment, > so I can't do proper testing. It makes sense for someone at Oracle to > make more extensive changes. Feel free to do a friendly takeover of > this change. The total amount of work will end up smallest > if JDK-8165620 actually gets tackled. Yeah, the matrix of "supported" build/run platforms makes it harder. Your patch is fine for now. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Fri Sep 9 14:54:56 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 9 Sep 2016 07:54:56 -0700 Subject: RFR: 8165643: SecureDirectoryStream doesn't work on linux non-x86 In-Reply-To: References: <2243547c-4b1b-abc2-8be7-de33d812e67c@oracle.com>

Message-ID: I pushed this fix, but also created the obvious follow-on fix https://bugs.openjdk.java.net/browse/JDK-8165776 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/SecureDirectoryStream-non-x86-32bit/ Completely untested, as advertised! On Thu, Sep 8, 2016 at 11:45 AM, Alan Bateman wrote: > On 08/09/2016 17:10, Martin Buchholz wrote: > > > > On Thu, Sep 8, 2016 at 1:06 AM, Alan Bateman > wrote: > >> On 07/09/2016 22:52, Martin Buchholz wrote: >> >> Hi Alan and Chris, >>> >>> Here's a bad fix for >>> https://bugs.openjdk.java.net/browse/JDK-8165643 >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/SecureDi >>> rectoryStream-non-x86/ >> Emartin/webrevs/openjdk9/SecureDirectoryStream-non-x86/> >>> >> I wonder if we can remove fstatat64_wrapper completely, the reason this >> code has this is because the support for this function was patchy at the >> time (some of the platform/versions that the JDK was supported on didn't >> have it). If you don't want to go that far then that is okay, I just wonder >> if you could at least avoid have one for i386 and one for 64-bit. > > > It's straightforward to extend my patch to the __i386 case. It's somewhat > less straightforward to add configure tests for all the *at functions > here. But I only have access to 64-bit Linux at the moment, so I can't do > proper testing. It makes sense for someone at Oracle to make more > extensive changes. Feel free to do a friendly takeover of this change. > The total amount of work will end up smallest if JDK-8165620 actually gets > tackled. > > Yeah, the matrix of "supported" build/run platforms makes it harder. Your > patch is fine for now. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdk at triemax.com Wed Sep 14 15:47:42 2016 From: jdk at triemax.com (Marco Hunsicker) Date: Wed, 14 Sep 2016 17:47:42 +0200 Subject: Support comment and extra attributes with zipfs Message-ID: <9a0654e2-c936-080d-0478-924db22dd2dd@triemax.com> Hi, great to see that the zip file system provider has been promoted to official status! I've recently started to play with it and I really like the unified way to perform I/O. I wish there were already more providers available... Anyway, I've ran into a major problem with zipfs for my needs: setting and getting comments for individual entries is not supported! I've created a ticket (Review ID: JI-9043744), but thought a message here probably won't hurt. The basic bits are there (in ZipFileSystem.java), but the attribute is not exposed to the outside world (through ZipFileAttributeView.java). The necessary changes are trivial though. Maybe this would be something that could still be added in time for Java 9? I've applied the necessary changes to my local copy of the JDK 8 demo sources and find it working well for me. Please let me know if you need any details. The "extra" attribute is missing support as well, but here the situation seems to be worse. I was not able to read an extra attribute that has been set with the oldschool API after applying the same changes as for the "comment" attribute (Linux 64 bit JDK 8.0_102-b14). There might be a a bug with ZipFileSystem.Entry. Looking at the test harness, I could not find any tests that deal with zip specific attributes, but I might be missing something. Thanks. Cheers, Marco From xueming.shen at oracle.com Wed Sep 14 16:24:58 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 14 Sep 2016 09:24:58 -0700 Subject: Support comment and extra attributes with zipfs In-Reply-To: <9a0654e2-c936-080d-0478-924db22dd2dd@triemax.com> References: <9a0654e2-c936-080d-0478-924db22dd2dd@triemax.com> Message-ID: <5e007245-1162-146f-8f2e-2df96293657c@oracle.com> +1 On 9/14/16 8:47 AM, Marco Hunsicker wrote: > Hi, > > great to see that the zip file system provider has been promoted to > official status! I've recently started to play with it and I really > like the unified way to perform I/O. I wish there were already more > providers available... > > Anyway, I've ran into a major problem with zipfs for my needs: setting > and getting comments for individual entries is not supported! > > I've created a ticket (Review ID: JI-9043744), but thought a message > here probably won't hurt. > > The basic bits are there (in ZipFileSystem.java), but the attribute is > not exposed to the outside world (through ZipFileAttributeView.java). > The necessary changes are trivial though. Maybe this would be > something that could still be added in time for Java 9? > > I've applied the necessary changes to my local copy of the JDK 8 demo > sources and find it working well for me. Please let me know if you > need any details. > > > The "extra" attribute is missing support as well, but here the > situation seems to be worse. I was not able to read an extra attribute > that has been set with the oldschool API after applying the same > changes as for the "comment" attribute (Linux 64 bit JDK 8.0_102-b14). > There might be a a bug with ZipFileSystem.Entry. > > Looking at the test harness, I could not find any tests that deal with > zip specific attributes, but I might be missing something. Thanks. > > Cheers, > Marco From brian.burkhalter at oracle.com Wed Sep 14 21:13:04 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 14 Sep 2016 14:13:04 -0700 Subject: JDK 9 RFR of 8165323: (fs) Files.getFileStore fails with "Mount point not found" in chroot environment Message-ID: <917F9974-4FA5-406D-B5D9-5C0908255353@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8165323 Patch: [1] The build failure is due to the attempt to create a FileStore which on Linux requires that ?/proc/mounts? exists and contains an entry for the ultimate parent of the path of interest. The path of interest in this case is one for which it is desired to determine whether a PosixFileAttributeView is supported. In a chroot environment, /proc/mounts might not exist or it might contain only minimal content, e.g., $ cat /proc/mounts none /proc proc rw,relatime 0 0 The problem is circumvented by replacing the use of FileStore in jlink. With this change ?make images? succeeds in the chroot environment; a Linux-only standard regression test run is in progress. While this change fixes the problematic failure in the build, it does not address the inability to create a FileStore in a chroot environment. Perhaps a separate issue should be filed for this problem? In particular, might it be possible in a chroot environment to create some kind of (potentially faked-out) FileStore when the path for which it is desired is absolute? Thanks, Brian [1] diff --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java @@ -188,7 +188,8 @@ storeFiles(modules, release); - if (Files.getFileStore(root).supportsFileAttributeView(PosixFileAttributeView.class)) { + if (root.getFileSystem().supportedFileAttributeViews() + .contains("posix")) { // launchers in the bin directory need execute permission. // On Windows, "bin" also subdirectories containing jvm.dll. if (Files.isDirectory(bin)) { @@ -282,8 +283,8 @@ StandardOpenOption.CREATE_NEW)) { writer.write(sb.toString()); } - if (Files.getFileStore(root.resolve("bin")) - .supportsFileAttributeView(PosixFileAttributeView.class)) { + if (root.resolve("bin").getFileSystem() + .supportedFileAttributeViews().contains("posix")) { setExecutable(cmd); } From brian.burkhalter at oracle.com Wed Sep 14 21:35:57 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 14 Sep 2016 14:35:57 -0700 Subject: jdk9 builds failing with: java.io.IOException: Mount point not found In-Reply-To: <1272a9a5-0289-90b1-1d76-25101fa4a8a1@oracle.com> References: <476205fe-d831-52d5-7f62-9fcd50ca75f1@ubuntu.com> <1272a9a5-0289-90b1-1d76-25101fa4a8a1@oracle.com> Message-ID: On Aug 30, 2016, at 4:57 AM, Alan Bateman wrote: > On 30/08/2016 12:49, Matthias Klose wrote: > >> In some build environments jdk9 builds fail with >> >> Error: jdk.tools.jlink.plugin.PluginException: java.io.IOException: Mount point >> not found >> >> complete build log e.g. at >> https://launchpadlibrarian.net/281693434/buildlog_ubuntu-yakkety-arm64.openjdk-9_9~b133-1ubuntu1_BUILDING.txt.gz >> >> The issue is not new, popped up earlier as seen in >> http://mail.openjdk.java.net/pipermail/nio-dev/2009-May/000547.html >> >> However for some reason this code is not called during 7 and 8 builds, only for 9. > Can you submit a bug on this? It's possible that there hasn't been much testing in chroot environments. > > As to why you are seeing this with JDK 9 builds then it is because the build runs jlink to create the run-time image. In JDK 8 and older then it was done by recipes in the build. Looping in nio-dev which is the appropriate mailing list for this problem. Alan filed https://bugs.openjdk.java.net/browse/JDK-8165323 to track this. I just submitted a review request for a fix for the immediate build problem at http://mail.openjdk.java.net/pipermail/nio-dev/2016-September/003876.html Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Wed Sep 14 22:34:49 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 15 Sep 2016 00:34:49 +0200 Subject: JDK 9 RFR of 8165323: (fs) Files.getFileStore fails with "Mount point not found" in chroot environment In-Reply-To: <917F9974-4FA5-406D-B5D9-5C0908255353@oracle.com> References: <917F9974-4FA5-406D-B5D9-5C0908255353@oracle.com> Message-ID: <57D9D089.1050208@oracle.com> Seems like a reasonable fix to the immediate issue. Thanks! /Claes On 2016-09-14 23:13, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8165323 > Patch: [1] > > The build failure is due to the attempt to create a FileStore which on Linux requires that ?/proc/mounts? exists and contains an entry for the ultimate parent of the path of interest. The path of interest in this case is one for which it is desired to determine whether a PosixFileAttributeView is supported. In a chroot environment, /proc/mounts might not exist or it might contain only minimal content, e.g., > > $ cat /proc/mounts > none /proc proc rw,relatime 0 0 > > The problem is circumvented by replacing the use of FileStore in jlink. With this change ?make images? succeeds in the chroot environment; a Linux-only standard regression test run is in progress. > > While this change fixes the problematic failure in the build, it does not address the inability to create a FileStore in a chroot environment. Perhaps a separate issue should be filed for this problem? In particular, might it be possible in a chroot environment to create some kind of (potentially faked-out) FileStore when the path for which it is desired is absolute? > > Thanks, > > Brian > > [1] diff > > --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java > +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java > @@ -188,7 +188,8 @@ > > storeFiles(modules, release); > > - if (Files.getFileStore(root).supportsFileAttributeView(PosixFileAttributeView.class)) { > + if (root.getFileSystem().supportedFileAttributeViews() > + .contains("posix")) { > // launchers in the bin directory need execute permission. > // On Windows, "bin" also subdirectories containing jvm.dll. > if (Files.isDirectory(bin)) { > @@ -282,8 +283,8 @@ > StandardOpenOption.CREATE_NEW)) { > writer.write(sb.toString()); > } > - if (Files.getFileStore(root.resolve("bin")) > - .supportsFileAttributeView(PosixFileAttributeView.class)) { > + if (root.resolve("bin").getFileSystem() > + .supportedFileAttributeViews().contains("posix")) { > setExecutable(cmd); > } > From sergei.kovalev at oracle.com Thu Sep 15 12:48:22 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Thu, 15 Sep 2016 15:48:22 +0300 Subject: RFR(s): 8166126: Missing dependecies on jdk.zipfs module for jdk/nio/zipfs/jarfs/JFSTester.java In-Reply-To: <0dbf5caa-d286-c210-2730-83c1a7803d48@oracle.com> References: <0dbf5caa-d286-c210-2730-83c1a7803d48@oracle.com> Message-ID: Hello team, Could you please review very small fix for single test. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166126 WebRev: http://cr.openjdk.java.net/~skovalev/8166126/webrev.00/ Problem: The test failed in case no jdk.zipfs module present in custom JRE or in case usage of --limi-modules options. Solution: Add module declaration for jdk.zipfs module to the test header. -- With best regards, Sergei From Alan.Bateman at oracle.com Thu Sep 15 13:21:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Sep 2016 06:21:47 -0700 Subject: RFR(s): 8166126: Missing dependecies on jdk.zipfs module for jdk/nio/zipfs/jarfs/JFSTester.java In-Reply-To: References: <0dbf5caa-d286-c210-2730-83c1a7803d48@oracle.com> Message-ID: On 15/09/2016 05:48, Sergei Kovalev wrote: > Hello team, > > Could you please review very small fix for single test. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166126 > WebRev: http://cr.openjdk.java.net/~skovalev/8166126/webrev.00/ > > Problem: The test failed in case no jdk.zipfs module present in custom > JRE or in case usage of --limi-modules options. > Solution: Add module declaration for jdk.zipfs module to the test header. > Looks okay. -Alan From brian.burkhalter at oracle.com Tue Sep 20 20:13:04 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 20 Sep 2016 13:13:04 -0700 Subject: JDK 9 RFR of 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8166253 Patch: http://cr.openjdk.java.net/~bpb/8166253/webrev.00/ Add an implementation note indicating that the lock could be released if the caller does not retain the returned object as a strongly reachable variable. If this looks reasonable a CCC request will be filed and the issue labels updated as needed. Thanks, Brian From sergei.kovalev at oracle.com Thu Sep 22 13:35:35 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Thu, 22 Sep 2016 16:35:35 +0300 Subject: RFR(s): 8166553: undeclared dependencies for two IO tests Message-ID: <5325c40d-9f94-9ac3-f073-a744e33f79eb@oracle.com> Hello team, Please review very small fix for two regression tests. BugID: https://bugs.openjdk.java.net/browse/JDK-8166553 Webrev: http://cr.openjdk.java.net/~skovalev/8166553/webrev.00/ Issue: tests failing in case of "--limit-modules java.base" command line option of vm. Root cause: undeclared dependencies on jdk modules. Solution: added declaration of required modules into jtreg header. -- With best regards, Sergei From brian.burkhalter at oracle.com Thu Sep 22 18:27:56 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 22 Sep 2016 11:27:56 -0700 Subject: RFR(s): 8166553: undeclared dependencies for two IO tests In-Reply-To: <5325c40d-9f94-9ac3-f073-a744e33f79eb@oracle.com> References: <5325c40d-9f94-9ac3-f073-a744e33f79eb@oracle.com> Message-ID: Hello Sergei, This looks OK to me. Thanks, Brian On Sep 22, 2016, at 6:35 AM, Sergei Kovalev wrote: > Hello team, > > Please review very small fix for two regression tests. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8166553 > Webrev: http://cr.openjdk.java.net/~skovalev/8166553/webrev.00/ > > Issue: tests failing in case of "--limit-modules java.base" command line option of vm. > Root cause: undeclared dependencies on jdk modules. > Solution: added declaration of required modules into jtreg header. > > -- > With best regards, > Sergei From christoph.langer at sap.com Fri Sep 23 07:18:47 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 23 Sep 2016 07:18:47 +0000 Subject: RFR(XS): 8166604: nio: remove unneeded locals variables and correct NPE Message-ID: <03061daf049f4401a32132883936d8c7@DEWDFE13DE11.global.corp.sap> Hi, please review a small cleanup in nio socket and datagram channel that I have spotted. I would even suggest to completely remove the null check throwing NPE in DatagramChannelImpl.receive(ByteBuffer dst) as an NPE would implicitly be thrown when dst is null and dst.isReadOnly() is called. The current behavior would not change then. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166604.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8166604 Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Sep 23 14:15:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Sep 2016 15:15:22 +0100 Subject: RFR(XS): 8166604: nio: remove unneeded locals variables and correct NPE In-Reply-To: <03061daf049f4401a32132883936d8c7@DEWDFE13DE11.global.corp.sap> References: <03061daf049f4401a32132883936d8c7@DEWDFE13DE11.global.corp.sap> Message-ID: On 23/09/2016 08:18, Langer, Christoph wrote: > Hi, > > please review a small cleanup in nio socket and datagram channel that > I have spotted. > > I would even suggest to completely remove the null check throwing NPE > in DatagramChannelImpl.receive(ByteBuffer dst) as an NPE would > implicitly be thrown when dst is null and dst.isReadOnly() is called. > The current behavior would not change then. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166604.0/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166604 > > > Checking dst for null is redundant as you observe but what you have in the current patch looks fine. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Sep 23 14:21:30 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 23 Sep 2016 14:21:30 +0000 Subject: RFR(XS): 8166604: nio: remove unneeded locals variables and correct NPE In-Reply-To: References: <03061daf049f4401a32132883936d8c7@DEWDFE13DE11.global.corp.sap> Message-ID: Thanks, Alan, for reviewing. If I don't hear otherwise, I'll push this on monday with the dst null check completely removed. Best regards Christoph From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Freitag, 23. September 2016 16:15 To: Langer, Christoph ; nio-dev at openjdk.java.net Subject: Re: RFR(XS): 8166604: nio: remove unneeded locals variables and correct NPE On 23/09/2016 08:18, Langer, Christoph wrote: Hi, please review a small cleanup in nio socket and datagram channel that I have spotted. I would even suggest to completely remove the null check throwing NPE in DatagramChannelImpl.receive(ByteBuffer dst) as an NPE would implicitly be thrown when dst is null and dst.isReadOnly() is called. The current behavior would not change then. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166604.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8166604 Checking dst for null is redundant as you observe but what you have in the current patch looks fine. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Sep 26 18:41:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Sep 2016 19:41:48 +0100 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com>

<9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> Message-ID: <062c589c-fa54-1652-683a-4e779816391d@oracle.com> On 26/09/2016 19:17, Lu, Yingqi wrote: > Hi All, > > The second version of the patch is now available at http://cr.openjdk.java.net/~igraves/8164900-1/. In this version, we moved the O_DIRECT support from FIS/FOS/RAF to FileChannel. We implemented O_DIRECT as a StandardOpenOption. The reason we did not make it as one of the ExtendedOpenOptions is because we found ExtendedOpenOption is now moved to jdk.unsupported. Please let us know if we misunderstood anything here. We can modify it accordingly if there is a better place to put this flag. ExtendedOpenOption seems the right place for this (we haven't found a good home for this yet). I skimmed the implementation and the changes to readv0/write0 are a concern - I suspect you'll need to hoist the bulk of this into FileChannelImpl so that most of this native code can be eliminated. -Alan From Alan.Bateman at oracle.com Tue Sep 27 15:45:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Sep 2016 16:45:17 +0100 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com>

<9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> Alan, Thank you for the explanation, we will modify the code accordingly and send it out soon for review. Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, September 27, 2016 8:45 AM To: Lu, Yingqi ; core-libs-dev at openjdk.java.net Cc: nio-dev at openjdk.java.net Subject: Re: Proposal for adding O_DIRECT support into JDK 9 On 26/09/2016 19:50, Lu, Yingqi wrote: > Alan, you mean readv0/write0 or read0/write0? I just want to make sure > :-) Apologies, I meant each of the native methods where the decision to use direct I/O or not would be a lot more maintainable in Java. You'll see that there are already code paths for direct vs. heap buffers. > > Anyone else has other opinions on where is the best home for O_DIRECT flag? The flags under jdk.unsupported will eventually be removed in the future JDK release? > > If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify that for sure. > I think ExtendedOpenOption is the right place. It's still TDB as to whether to put these extensions but that should be transparent to anyone using this when on the class path. -Alan From christoph.langer at sap.com Wed Sep 28 22:08:26 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Sep 2016 22:08:26 +0000 Subject: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c Message-ID: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> Hi, Please review: The file java.base/aix/native/libnio/ch/AixNativeThread.c does not differ significantly from java.base/unix/native/libnio/ch/NativeThread.c, except for 3 #include/#define statements as for any other distinct unix platform. So this should be consolidated. Bug: https://bugs.openjdk.java.net/browse/JDK-8166866 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166866.0/ Thanks & best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Sep 29 07:33:05 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 29 Sep 2016 09:33:05 +0200 Subject: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c In-Reply-To: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> References: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> Message-ID: Hi Christoph, looks good! Thanks for cleaning this up, Volker On Thu, Sep 29, 2016 at 12:08 AM, Langer, Christoph wrote: > Hi, > > > > Please review: The file java.base/aix/native/libnio/ch/AixNativeThread.c > does not differ significantly from > java.base/unix/native/libnio/ch/NativeThread.c, except for 3 > #include/#define statements as for any other distinct unix platform. So this > should be consolidated. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166866 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166866.0/ > > > > Thanks & best regards > > Christoph > > From chris.hegarty at oracle.com Thu Sep 29 08:27:13 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 29 Sep 2016 09:27:13 +0100 Subject: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c In-Reply-To: References: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> Message-ID: <21A77B03-59B6-45BB-A30D-7BA3F97B71B5@oracle.com> > On 29 Sep 2016, at 08:33, Volker Simonis wrote: > > Hi Christoph, > > looks good! +1. -Chris. > Thanks for cleaning this up, > Volker > > > On Thu, Sep 29, 2016 at 12:08 AM, Langer, Christoph > wrote: >> Hi, >> >> >> >> Please review: The file java.base/aix/native/libnio/ch/AixNativeThread.c >> does not differ significantly from >> java.base/unix/native/libnio/ch/NativeThread.c, except for 3 >> #include/#define statements as for any other distinct unix platform. So this >> should be consolidated. >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166866 >> >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166866.0/ >> >> >> >> Thanks & best regards >> >> Christoph >> >> From Alan.Bateman at oracle.com Thu Sep 29 08:42:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Sep 2016 09:42:53 +0100 Subject: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c In-Reply-To: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> References: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> Message-ID: <6fb8b93b-ac20-0ac0-1f6e-e84152658642@oracle.com> On 28/09/2016 23:08, Langer, Christoph wrote: > Hi, > > Please review: The file > java.base/aix/native/libnio/ch/AixNativeThread.c does not differ > significantly from java.base/unix/native/libnio/ch/NativeThread.c, > except for 3 #include/#define statements as for any other distinct > unix platform. So this should be consolidated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166866 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166866.0/ > > > this looks okay to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Sep 29 13:07:42 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 29 Sep 2016 13:07:42 +0000 Subject: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c In-Reply-To: <6fb8b93b-ac20-0ac0-1f6e-e84152658642@oracle.com> References: <1ac8cf6728fa408f9ff059b57b0d534b@DEWDFE13DE11.global.corp.sap> <6fb8b93b-ac20-0ac0-1f6e-e84152658642@oracle.com> Message-ID: <70e5eb3a000f47578c301c6883f1c9a0@DEWDFE13DE11.global.corp.sap> Thanks, guys, for reviewing. I pushed it: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/91a5353ecbbb Best regards Christoph From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Donnerstag, 29. September 2016 10:43 To: Langer, Christoph ; nio-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(S): 8166866: (ch) Remove AIX specific implementation file java.base/aix/native/libnio/ch/AixNativeThread.c On 28/09/2016 23:08, Langer, Christoph wrote: Hi, Please review: The file java.base/aix/native/libnio/ch/AixNativeThread.c does not differ significantly from java.base/unix/native/libnio/ch/NativeThread.c, except for 3 #include/#define statements as for any other distinct unix platform. So this should be consolidated. Bug: https://bugs.openjdk.java.net/browse/JDK-8166866 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166866.0/ this looks okay to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Fri Sep 30 16:55:04 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 30 Sep 2016 16:55:04 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com>