From brian.burkhalter at oracle.com Fri Feb 3 22:07:51 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 3 Feb 2017 14:07:51 -0800 Subject: [TEST-BUG] JDK 9 RFR of 8173910: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8173910 Patch: http://cr.openjdk.java.net/~bpb/8173910/webrev.00/ Creation of a FileStore on Unix systems will hang if the stat(2) system call hangs which is the case for stale NFS mounts. The test is changed to spawn a ?df? command in a separate process and wait 90 seconds for that process to complete. If the process has not completed or its exit value is non-zero, the iteration over FileStores is omitted from the test. This should not affect most test runs and should suppress spurious failures due to stale NFS mounts. Thanks, Brian From Alan.Bateman at oracle.com Mon Feb 6 10:30:20 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Feb 2017 10:30:20 +0000 Subject: [TEST-BUG] JDK 9 RFR of 8173910: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores In-Reply-To: References: Message-ID: <3d4ec5b4-7c94-11eb-4458-faa87147489e@oracle.com> On 03/02/2017 22:07, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8173910 > Patch: http://cr.openjdk.java.net/~bpb/8173910/webrev.00/ > > Creation of a FileStore on Unix systems will hang if the stat(2) system call hangs which is the case for stale NFS mounts. The test is changed to spawn a ?df? command in a separate process and wait 90 seconds for that process to complete. If the process has not completed or its exit value is non-zero, the iteration over FileStores is omitted from the test. This should not affect most test runs and should suppress spurious failures due to stale NFS mounts. > Are there any other tests that run into this? I'm just wondering if this might be needed in the test infrastructure libraries. In any case, the approach seems okay although I think it would be better to move it into its own method to avoid cluttering main. I also have a small concern that it doesn't read the output/error streams from the `df` command and so could hang if there is a lot of output. ProcessUtils is probably useful for this. -Alan From claes.redestad at oracle.com Mon Feb 6 13:02:48 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 6 Feb 2017 14:02:48 +0100 Subject: RFR: 8173982: (fs) DefaultFileSystemProvider should be split into platform specific versions Message-ID: <21f88a0d-15c5-13e0-5ec3-3260194a14d4@oracle.com> Hi, sun.nio.fs.DefaultFileSystemProvider can now be implemented directly for each platform, removing the need for using reflection. Since 9 the DefaultFileSystemProvider is initialized on startup, thus this indirection can be shown to be cause for a small startup regression on unix platforms relative to windows. Bug: https://bugs.openjdk.java.net/browse/JDK-8173982 Webrev: http://cr.openjdk.java.net/~redestad/8173982/webrev.01/ Thanks! /Claes From Alan.Bateman at oracle.com Mon Feb 6 13:05:33 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Feb 2017 13:05:33 +0000 Subject: RFR: 8173982: (fs) DefaultFileSystemProvider should be split into platform specific versions In-Reply-To: <21f88a0d-15c5-13e0-5ec3-3260194a14d4@oracle.com> References: <21f88a0d-15c5-13e0-5ec3-3260194a14d4@oracle.com> Message-ID: <60366496-7017-3499-3bda-6bb534701df2@oracle.com> On 06/02/2017 13:02, Claes Redestad wrote: > Hi, > > sun.nio.fs.DefaultFileSystemProvider can now be implemented directly > for each platform, removing the need for using reflection. > > Since 9 the DefaultFileSystemProvider is initialized on startup, thus > this indirection can be shown to be cause for a small startup > regression on unix platforms relative to windows. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173982 > Webrev: http://cr.openjdk.java.net/~redestad/8173982/webrev.01/ This looks okay to me. -Alan From claes.redestad at oracle.com Mon Feb 6 13:08:49 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 6 Feb 2017 14:08:49 +0100 Subject: RFR: 8173982: (fs) DefaultFileSystemProvider should be split into platform specific versions In-Reply-To: <60366496-7017-3499-3bda-6bb534701df2@oracle.com> References: <21f88a0d-15c5-13e0-5ec3-3260194a14d4@oracle.com> <60366496-7017-3499-3bda-6bb534701df2@oracle.com> Message-ID: <576fb4d3-8ea1-c8c5-17c9-7e2c55e4663e@oracle.com> On 02/06/2017 02:05 PM, Alan Bateman wrote: > On 06/02/2017 13:02, Claes Redestad wrote: > >> Hi, >> >> sun.nio.fs.DefaultFileSystemProvider can now be implemented directly >> for each platform, removing the need for using reflection. >> >> Since 9 the DefaultFileSystemProvider is initialized on startup, thus >> this indirection can be shown to be cause for a small startup >> regression on unix platforms relative to windows. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8173982 >> Webrev: http://cr.openjdk.java.net/~redestad/8173982/webrev.01/ > This looks okay to me. > Thanks! //Claes > -Alan From christoph.langer at sap.com Mon Feb 6 21:33:29 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 6 Feb 2017 21:33:29 +0000 Subject: RFR: 8173982: (fs) DefaultFileSystemProvider should be split into platform specific versions In-Reply-To: <576fb4d3-8ea1-c8c5-17c9-7e2c55e4663e@oracle.com> References: <21f88a0d-15c5-13e0-5ec3-3260194a14d4@oracle.com> <60366496-7017-3499-3bda-6bb534701df2@oracle.com> <576fb4d3-8ea1-c8c5-17c9-7e2c55e4663e@oracle.com> Message-ID: Hi Claes, this looks good. I'm wondering if the same should be done with sun/nio/ch/DefaultAsynchronousChannelProvider.java ? Best regards Christoph > -----Original Message----- > From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of > Claes Redestad > Sent: Montag, 6. Februar 2017 14:09 > To: Alan Bateman ; nio-dev at openjdk.java.net > Subject: Re: RFR: 8173982: (fs) DefaultFileSystemProvider should be split into > platform specific versions > > > > On 02/06/2017 02:05 PM, Alan Bateman wrote: > > On 06/02/2017 13:02, Claes Redestad wrote: > > > >> Hi, > >> > >> sun.nio.fs.DefaultFileSystemProvider can now be implemented directly > >> for each platform, removing the need for using reflection. > >> > >> Since 9 the DefaultFileSystemProvider is initialized on startup, thus > >> this indirection can be shown to be cause for a small startup > >> regression on unix platforms relative to windows. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8173982 > >> Webrev: http://cr.openjdk.java.net/~redestad/8173982/webrev.01/ > > This looks okay to me. > > > > Thanks! > > //Claes > > > -Alan From claes.redestad at oracle.com Mon Feb 6 21:56:04 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 6 Feb 2017 22:56:04 +0100 Subject: RFR: 8173982: (fs) DefaultFileSystemProvider should be split into platform specific versions In-Reply-To: References: <21f88a0d-15c5-13e0-5ec3-3260194a14d4@oracle.com> <60366496-7017-3499-3bda-6bb534701df2@oracle.com> <576fb4d3-8ea1-c8c5-17c9-7e2c55e4663e@oracle.com> Message-ID: <8e111bad-6536-3940-f764-0b910ab3982f@oracle.com> Hi Christoph, oh, seems like the same pattern, yes. I unfortunately pushed this just before I got your reply, and even though it'd be a trivial fix to pile on, I think we must defer and do this as an enhancement for 10 at this point since there is no regression we could pin that on (AFAIK). Filed: https://bugs.openjdk.java.net/browse/JDK-8174039 Thanks! /Claes On 2017-02-06 22:33, Langer, Christoph wrote: > Hi Claes, > > this looks good. > > I'm wondering if the same should be done with sun/nio/ch/DefaultAsynchronousChannelProvider.java ? > > Best regards > Christoph > >> -----Original Message----- >> From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of >> Claes Redestad >> Sent: Montag, 6. Februar 2017 14:09 >> To: Alan Bateman ; nio-dev at openjdk.java.net >> Subject: Re: RFR: 8173982: (fs) DefaultFileSystemProvider should be split into >> platform specific versions >> >> >> >> On 02/06/2017 02:05 PM, Alan Bateman wrote: >>> On 06/02/2017 13:02, Claes Redestad wrote: >>> >>>> Hi, >>>> >>>> sun.nio.fs.DefaultFileSystemProvider can now be implemented directly >>>> for each platform, removing the need for using reflection. >>>> >>>> Since 9 the DefaultFileSystemProvider is initialized on startup, thus >>>> this indirection can be shown to be cause for a small startup >>>> regression on unix platforms relative to windows. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173982 >>>> Webrev: http://cr.openjdk.java.net/~redestad/8173982/webrev.01/ >>> This looks okay to me. >>> >> >> Thanks! >> >> //Claes >> >>> -Alan > From brian.burkhalter at oracle.com Mon Feb 6 22:54:54 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 Feb 2017 14:54:54 -0800 Subject: [TEST-BUG] JDK 9 RFR of 8173910: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores In-Reply-To: <3d4ec5b4-7c94-11eb-4458-faa87147489e@oracle.com> References: <3d4ec5b4-7c94-11eb-4458-faa87147489e@oracle.com> Message-ID: <768D1B09-740C-4D8F-AB0D-AB5A663D370D@oracle.com> On Feb 6, 2017, at 2:30 AM, Alan Bateman wrote: > Are there any other tests that run into this? I'm just wondering if this might be needed in the test infrastructure libraries. It?s possible. I > In any case, the approach seems okay although I think it would be better to move it into its own method to avoid cluttering main. I also have a small concern that it doesn't read the output/error streams from the `df` command and so could hang if there is a lot of output. ProcessUtils is probably useful for this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Feb 6 22:55:39 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 Feb 2017 14:55:39 -0800 Subject: [TEST-BUG] JDK 9 RFR of 8173910: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores In-Reply-To: <768D1B09-740C-4D8F-AB0D-AB5A663D370D@oracle.com> References: <3d4ec5b4-7c94-11eb-4458-faa87147489e@oracle.com> <768D1B09-740C-4D8F-AB0D-AB5A663D370D@oracle.com> Message-ID: <58862C9C-48B8-4139-B104-312CB5301410@oracle.com> Scratch this: I was working on a Draft and accidentally sent it ? On Feb 6, 2017, at 2:54 PM, Brian Burkhalter wrote: > On Feb 6, 2017, at 2:30 AM, Alan Bateman wrote: > >> Are there any other tests that run into this? I'm just wondering if this might be needed in the test infrastructure libraries. > > It?s possible. I > >> In any case, the approach seems okay although I think it would be better to move it into its own method to avoid cluttering main. I also have a small concern that it doesn't read the output/error streams from the `df` command and so could hang if there is a lot of output. ProcessUtils is probably useful for this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Feb 7 00:03:06 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 Feb 2017 16:03:06 -0800 Subject: [TEST-BUG] JDK 9 RFR of 8173910: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores In-Reply-To: <3d4ec5b4-7c94-11eb-4458-faa87147489e@oracle.com> References: <3d4ec5b4-7c94-11eb-4458-faa87147489e@oracle.com> Message-ID: On Feb 6, 2017, at 2:30 AM, Alan Bateman wrote: > Are there any other tests that run into this? I'm just wondering if this might be needed in the test infrastructure libraries. I looked through the issues involving timeouts which are assigned to me and did not see at a glance any other tests which might be facing this problem. > In any case, the approach seems okay although I think it would be better to move it into its own method to avoid cluttering main. Agreed; separated out in updated version. > I also have a small concern that it doesn't read the output/error streams from the `df` command and so could hang if there is a lot of output. Calling inheritIO() on the ProcessBuilder before starting the Process should take care of this (new version, line 63). > ProcessUtils is probably useful for this. An updated patch is here: http://cr.openjdk.java.net/~bpb/8173910/webrev.01/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Feb 7 00:47:27 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 Feb 2017 16:47:27 -0800 Subject: ByteBuffer to CharBuffer In-Reply-To: <33772099-d46d-9987-2b81-628e35be700d@yawk.at> References: <33772099-d46d-9987-2b81-628e35be700d@yawk.at> Message-ID: Looping in nio-dev which, as Pavel noted, is the apt forum for this topic. Jonas?s response is correct. The concept of ?view buffer? is specified by [1]. In particular the statement "A view buffer is simply another buffer whose content is backed by the byte buffer." at least to my interpretation signifies that the content of the view buffer is conceptually mapped bit-by-bit to / from the corresponding bits in the byte buffer. The details are of course subject to byte order and the like, and the interpretation of the bits for floating point values is according to IEEE 754. There is however no encoding or decoding applied. - Brian [1] http://download.java.net/java/jdk9/docs/api/java/nio/ByteBuffer.html#views On Feb 6, 2017, at 5:35 AM, Jonas Konrad wrote: > From what I can tell, asCharBuffer behaves exactly like the other as*Buffer methods, meaning every char in the CharBuffer is represented by two bytes in the original ByteBuffer (big- or little-endian depending on ByteOrder of the ByteBuffer). This means bb.asCharBuffer().get() behaves like bb.getChar(). asCharBuffer does *not* decode using any Charset (not the platform charset either), it just interprets the bytes as 16-bit unsigned integers which happen to be the char type in java. I guess this technically counts as UTF-16? It doesn't do validity checks either, though. > > If you wish to decode a ByteBuffer, you can use the CharsetDecoder API directly. I do not believe an asCharBuffer-like method which decodes on the fly is possible generally for all charsets, because decoding is not necessarily possible in a random-access buffer due to dynamic-width encoding. > > - Jonas Konrad > > On 02/06/2017 11:57 AM, Jay wrote: >> java.nio.ByteBuffer provides a method asCharBuffer() which returns a >> "view" of the ByteBuffer as a character buffer. It however does not >> take any arguments. And there is no mention in the Javadocs as to how >> it converts from bytes to chars. >> >> 1. There should be a method ByteBuffer.asCharBuffer(CharSet) and/or >> ByteBuffer.asCharBuffer(String charSet) which allows the user to >> explicitly specify the character set to be used for conversion. >> >> 2. The method ByteBuffer.asCharBuffer() should mention that this >> method uses the platform default charset for bytes-to-chars >> conversion. >> >> I can provide a patch with these two changes. What do you guys think? >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Feb 7 11:54:20 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 7 Feb 2017 11:54:20 +0000 Subject: RFR: 8174039: (ch) DefaultAsynchronousChannelProvider should be split into platform specific versions Message-ID: Hi, as discussed yesterday in http://mail.openjdk.java.net/pipermail/nio-dev/2017-February/004107.html, there is another potential for improvement like https://bugs.openjdk.java.net/browse/JDK-8173982. Bug: https://bugs.openjdk.java.net/browse/JDK-8174039 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8174039.0/ I also made a little cleanup in DefaultSelectorProvider.java. The webrev is based on JDK9. Please let me know if this could still go there or if I should do it in JDK10. I think the change is rather explicit and clear - so maybe there's a chance for 9, still? Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Feb 7 11:59:59 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Feb 2017 11:59:59 +0000 Subject: RFR: 8174039: (ch) DefaultAsynchronousChannelProvider should be split into platform specific versions In-Reply-To: References: Message-ID: <347d288c-27fe-05f6-bb41-c1ea2148e2d0@oracle.com> On 07/02/2017 11:54, Langer, Christoph wrote: > > Hi, > > as discussed yesterday in > http://mail.openjdk.java.net/pipermail/nio-dev/2017-February/004107.html, > there is another potential for improvement like > https://bugs.openjdk.java.net/browse/JDK-8173982. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8174039 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8174039.0/ > > > I also made a little cleanup in DefaultSelectorProvider.java. > > The webrev is based on JDK9. Please let me know if this could still go > there or if I should do it in JDK10. I think the change is rather > explicit and clear ? so maybe there?s a chance for 9, still? > > This looks okay to me. At this point in the release when P4 and P5 issues are meant to be deferred. So it seems like something for JDK 10 to me. The reason that the FileSystemProvider change was important for JDK 9 is because it's related to a small regression in startup performance. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Feb 7 12:30:41 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 7 Feb 2017 12:30:41 +0000 Subject: RFR: 8174039: (ch) DefaultAsynchronousChannelProvider should be split into platform specific versions In-Reply-To: <347d288c-27fe-05f6-bb41-c1ea2148e2d0@oracle.com> References: <347d288c-27fe-05f6-bb41-c1ea2148e2d0@oracle.com> Message-ID: <438c90b4d3bc4281bd97fc92a25b72cf@derote13de46.global.corp.sap> Thanks Alan for the quick review. I'll push it to JDK10 then. Best regards Christoph From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Dienstag, 7. Februar 2017 13:00 To: Langer, Christoph ; nio-dev at openjdk.java.net Subject: Re: RFR: 8174039: (ch) DefaultAsynchronousChannelProvider should be split into platform specific versions On 07/02/2017 11:54, Langer, Christoph wrote: Hi, as discussed yesterday in http://mail.openjdk.java.net/pipermail/nio-dev/2017-February/004107.html, there is another potential for improvement like https://bugs.openjdk.java.net/browse/JDK-8173982. Bug: https://bugs.openjdk.java.net/browse/JDK-8174039 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8174039.0/ I also made a little cleanup in DefaultSelectorProvider.java. The webrev is based on JDK9. Please let me know if this could still go there or if I should do it in JDK10. I think the change is rather explicit and clear - so maybe there's a chance for 9, still? This looks okay to me. At this point in the release when P4 and P5 issues are meant to be deferred. So it seems like something for JDK 10 to me. The reason that the FileSystemProvider change was important for JDK 9 is because it's related to a small regression in startup performance. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Tue Feb 7 13:22:31 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 7 Feb 2017 14:22:31 +0100 Subject: RFR: 8174039: (ch) DefaultAsynchronousChannelProvider should be split into platform specific versions In-Reply-To: <438c90b4d3bc4281bd97fc92a25b72cf@derote13de46.global.corp.sap> References: <347d288c-27fe-05f6-bb41-c1ea2148e2d0@oracle.com> <438c90b4d3bc4281bd97fc92a25b72cf@derote13de46.global.corp.sap> Message-ID: <929df67d-6830-4e30-e3bb-d2ad7f1dae0e@oracle.com> +1 Thanks for doing this! /Claes On 02/07/2017 01:30 PM, Langer, Christoph wrote: > > Thanks Alan for the quick review. > > I?ll push it to JDK10 then. > > Best regards > > Christoph > > *From:*Alan Bateman [mailto:Alan.Bateman at oracle.com] > *Sent:* Dienstag, 7. Februar 2017 13:00 > *To:* Langer, Christoph ; > nio-dev at openjdk.java.net > *Subject:* Re: RFR: 8174039: (ch) DefaultAsynchronousChannelProvider > should be split into platform specific versions > > On 07/02/2017 11:54, Langer, Christoph wrote: > > Hi, > > as discussed yesterday in > http://mail.openjdk.java.net/pipermail/nio-dev/2017-February/004107.html, > there is another potential for improvement like > https://bugs.openjdk.java.net/browse/JDK-8173982. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8174039 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8174039.0/ > > > I also made a little cleanup in DefaultSelectorProvider.java. > > The webrev is based on JDK9. Please let me know if this could > still go there or if I should do it in JDK10. I think the change > is rather explicit and clear ? so maybe there?s a chance for 9, still? > > This looks okay to me. > > At this point in the release when P4 and P5 issues are meant to be > deferred. So it seems like something for JDK 10 to me. The reason that > the FileSystemProvider change was important for JDK 9 is because it's > related to a small regression in startup performance. > > -Alan > From brian.burkhalter at oracle.com Tue Feb 7 15:50:40 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 7 Feb 2017 07:50:40 -0800 Subject: RFR: 8174039: (ch) DefaultAsynchronousChannelProvider should be split into platform specific versions In-Reply-To: <929df67d-6830-4e30-e3bb-d2ad7f1dae0e@oracle.com> References: <347d288c-27fe-05f6-bb41-c1ea2148e2d0@oracle.com> <438c90b4d3bc4281bd97fc92a25b72cf@derote13de46.global.corp.sap> <929df67d-6830-4e30-e3bb-d2ad7f1dae0e@oracle.com> Message-ID: <11EFC2EB-13AE-4654-A3CE-4FC75B7741F7@oracle.com> Another +1 from me. Thanks, Brian On Feb 7, 2017, at 5:22 AM, Claes Redestad wrote: > +1 > > Thanks for doing this! > > /Claes > > On 02/07/2017 01:30 PM, Langer, Christoph wrote: >> >> Thanks Alan for the quick review. >> >> I?ll push it to JDK10 then. >> >> Best regards >> >> Christoph >> >> *From:*Alan Bateman [mailto:Alan.Bateman at oracle.com] >> *Sent:* Dienstag, 7. Februar 2017 13:00 >> *To:* Langer, Christoph ; nio-dev at openjdk.java.net >> *Subject:* Re: RFR: 8174039: (ch) DefaultAsynchronousChannelProvider should be split into platform specific versions >> >> On 07/02/2017 11:54, Langer, Christoph wrote: >> >> Hi, >> >> as discussed yesterday in >> http://mail.openjdk.java.net/pipermail/nio-dev/2017-February/004107.html, >> there is another potential for improvement like >> https://bugs.openjdk.java.net/browse/JDK-8173982. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8174039 >> >> >> Webrev:http://cr.openjdk.java.net/~clanger/webrevs/8174039.0/ >> >> >> I also made a little cleanup in DefaultSelectorProvider.java. >> >> The webrev is based on JDK9. Please let me know if this could >> still go there or if I should do it in JDK10. I think the change >> is rather explicit and clear ? so maybe there?s a chance for 9, still? >> >> This looks okay to me. >> >> At this point in the release when P4 and P5 issues are meant to be deferred. So it seems like something for JDK 10 to me. The reason that the FileSystemProvider change was important for JDK 9 is because it's related to a small regression in startup performance. >> >> -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Feb 7 17:46:12 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Feb 2017 17:46:12 +0000 Subject: [TEST-BUG] JDK 9 RFR of 8173910: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores In-Reply-To: References: <3d4ec5b4-7c94-11eb-4458-faa87147489e@oracle.com> Message-ID: <7271880d-3935-0cb8-7bac-94c910d6a5fa@oracle.com> On 07/02/2017 00:03, Brian Burkhalter wrote: >> ProcessUtils is probably useful for this. > > An updated patch is here: > http://cr.openjdk.java.net/~bpb/8173910/webrev.01/ > > This update looks okay. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Feb 7 22:22:20 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 7 Feb 2017 14:22:20 -0800 Subject: [TEST-BUG] JDK 9 RFR of 8174127: (ch) Add instrumentation to java/nio/channels/FileChannel/Transfer.java Message-ID: <234BA9F2-B97D-44C9-AA85-321D1B2DC068@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8174127 Patch: http://cr.openjdk.java.net/~bpb/8174127/webrev.00/ The purpose of this change is to instrument the test in question to provide information which might eventually lead to a fix for [1]. Debugging statements are added to the test to show which tests have been effected. Also, instead of exiting upon the first test failure, all tests are run and a failure count is kept with the overall test failing if that count is non-zero at the end. The test library utility also RandomFactory replaces the direct instantiation of Random to provide the ability to manage the randomness in the test. A regression job with slightly different content succeeded on all platforms; a job with the current patch is in progress. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8140263 From brian.burkhalter at oracle.com Thu Feb 9 02:20:48 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 8 Feb 2017 18:20:48 -0800 Subject: [TEST-BUG] JDK 9 RFR of 8173387: java/nio/channels/Selector/SelectTimeout.java failed with "Test timed out early with timeout 100000000999" Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8173387 Patch: http://cr.openjdk.java.net/~bpb/8173387/webrev.00/ The problem was due to different threads updating the same static variables. Thanks, Brian From christoph.langer at sap.com Thu Feb 9 06:38:05 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 9 Feb 2017 06:38:05 +0000 Subject: [TEST-BUG] JDK 9 RFR of 8173387: java/nio/channels/Selector/SelectTimeout.java failed with "Test timed out early with timeout 100000000999" In-Reply-To: References: Message-ID: <15fe91f208624e0fa2da9620e7c073fb@derote13de46.global.corp.sap> Hi Brian, this looks good. Not a reviewer, though. Best regards Christoph > -----Original Message----- > From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of > Brian Burkhalter > Sent: Donnerstag, 9. Februar 2017 03:21 > To: nio-dev > Subject: [TEST-BUG] JDK 9 RFR of 8173387: > java/nio/channels/Selector/SelectTimeout.java failed with "Test timed out > early with timeout 100000000999" > > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8173387 > Patch: http://cr.openjdk.java.net/~bpb/8173387/webrev.00/ > > The problem was due to different threads updating the same static variables. > > Thanks, > > Brian From Alan.Bateman at oracle.com Thu Feb 9 10:01:42 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Feb 2017 10:01:42 +0000 Subject: [TEST-BUG] JDK 9 RFR of 8173387: java/nio/channels/Selector/SelectTimeout.java failed with "Test timed out early with timeout 100000000999" In-Reply-To: References: Message-ID: On 09/02/2017 02:20, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8173387 > Patch: http://cr.openjdk.java.net/~bpb/8173387/webrev.00/ > > The problem was due to different threads updating the same static variables. > This looks okay to me. -Alan From Alan.Bateman at oracle.com Thu Feb 9 11:31:34 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Feb 2017 11:31:34 +0000 Subject: [TEST-BUG] JDK 9 RFR of 8174127: (ch) Add instrumentation to java/nio/channels/FileChannel/Transfer.java In-Reply-To: <234BA9F2-B97D-44C9-AA85-321D1B2DC068@oracle.com> References: <234BA9F2-B97D-44C9-AA85-321D1B2DC068@oracle.com> Message-ID: On 07/02/2017 22:22, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8174127 > Patch: http://cr.openjdk.java.net/~bpb/8174127/webrev.00/ > > The purpose of this change is to instrument the test in question to provide information which might eventually lead to a fix for [1]. Debugging statements are added to the test to show which tests have been effected. Also, instead of exiting upon the first test failure, all tests are run and a failure count is kept with the overall test failing if that count is non-zero at the end. The test library utility also RandomFactory replaces the direct instantiation of Random to provide the ability to manage the randomness in the test. > > I think it would be better to just convert it to a TestNG test. Also for the time out issue then I think there is enough in the original bug to see that it usually times out in Test08 which involves a 6GB file. It might be useful to put some output in that test so that you can see how long it takes to create the file. It might also be useful to increase the timeout on this test, just in case it is running close to the limit on some of these test machines. -Alan. From brian.burkhalter at oracle.com Thu Feb 9 20:31:25 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 9 Feb 2017 12:31:25 -0800 Subject: [TEST-BUG] JDK 9 RFR of 8174127: (ch) Add instrumentation to java/nio/channels/FileChannel/Transfer.java In-Reply-To: References: <234BA9F2-B97D-44C9-AA85-321D1B2DC068@oracle.com> Message-ID: <296419E7-4DD3-4C04-AB78-D2746C3028B1@oracle.com> On Feb 9, 2017, at 3:31 AM, Alan Bateman wrote: > I think it would be better to just convert it to a TestNG test. I concur. > Also for the time out issue then I think there is enough in the original bug to see that it usually times out in Test08 which involves a 6GB file. It might be useful to put some output in that test so that you can see how long it takes to create the file. Done: http://cr.openjdk.java.net/~bpb/8174127/webrev.01/ > It might also be useful to increase the timeout on this test, just in case it is running close to the limit on some of these test machines. I think I?ll leave that alone for now in order first to see what insight the new test output provides. There is another test which I think is running close to the limit: https://bugs.openjdk.java.net/browse/JDK-8140263. The output in one of the failure logs for this one actually includes ?Test succeeded? as printed from the test itself but the test still fails. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 9 21:53:13 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Feb 2017 21:53:13 +0000 Subject: [TEST-BUG] JDK 9 RFR of 8174127: (ch) Add instrumentation to java/nio/channels/FileChannel/Transfer.java In-Reply-To: <296419E7-4DD3-4C04-AB78-D2746C3028B1@oracle.com> References: <234BA9F2-B97D-44C9-AA85-321D1B2DC068@oracle.com> <296419E7-4DD3-4C04-AB78-D2746C3028B1@oracle.com> Message-ID: <56af618b-b96d-530d-d9c9-d5a7e6be6d37@oracle.com> On 09/02/2017 20:31, Brian Burkhalter wrote: > On Feb 9, 2017, at 3:31 AM, Alan Bateman > wrote: > >> I think it would be better to just convert it to a TestNG test. > > I concur. > >> Also for the time out issue then I think there is enough in the >> original bug to see that it usually times out in Test08 which >> involves a 6GB file. It might be useful to put some output in that >> test so that you can see how long it takes to create the file. > > Done: http://cr.openjdk.java.net/~bpb/8174127/webrev.01/ > This looks good. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Feb 13 16:28:12 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 13 Feb 2017 16:28:12 +0000 Subject: JDK10: RFR (S): 8174834: nio (ch): Remove #ifdef AF_INET6 guards in native coding Message-ID: <6383c30b9bd446ecb88a34cae9f5bd0e@derote13de46.global.corp.sap> Hi, please review a small cleanup for JDK10. The #ifdef AF_INET6 sections can be cleaned up in libnio native coding - just as it was done for libnet already (JDK-8168771). Bug: https://bugs.openjdk.java.net/browse/JDK-8174834 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8174834.0/ Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Feb 14 11:07:01 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Feb 2017 11:07:01 +0000 Subject: JDK10: RFR (S): 8174834: nio (ch): Remove #ifdef AF_INET6 guards in native coding In-Reply-To: <6383c30b9bd446ecb88a34cae9f5bd0e@derote13de46.global.corp.sap> References: <6383c30b9bd446ecb88a34cae9f5bd0e@derote13de46.global.corp.sap> Message-ID: <54fa7ea8-4e90-b5c6-a0fd-c199665cb9c6@oracle.com> On 13/02/2017 16:28, Langer, Christoph wrote: > Hi, > > please review a small cleanup for JDK10. The #ifdef AF_INET6 sections > can be cleaned up in libnio native coding ? just as it was done for > libnet already (JDK-8168771 > ). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8174834 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8174834.0/ > > > This looks okay to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Feb 14 12:32:12 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 Feb 2017 12:32:12 +0000 Subject: JDK10: RFR (S): 8174834: nio (ch): Remove #ifdef AF_INET6 guards in native coding In-Reply-To: <6383c30b9bd446ecb88a34cae9f5bd0e@derote13de46.global.corp.sap> References: <6383c30b9bd446ecb88a34cae9f5bd0e@derote13de46.global.corp.sap> Message-ID: <9258B546-0B8C-4EE3-BD92-3B3D642A77B1@oracle.com> > On 13 Feb 2017, at 16:28, Langer, Christoph wrote: > > Hi, > > please review a small cleanup for JDK10. The #ifdef AF_INET6 sections can be cleaned up in libnio native coding ? just as it was done for libnet already (JDK-8168771). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8174834 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8174834.0/ Looks good Christoph. -Chris. From christoph.langer at sap.com Wed Feb 15 13:55:12 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 15 Feb 2017 13:55:12 +0000 Subject: JDK10: RFR (S): 8174834: nio (ch): Remove #ifdef AF_INET6 guards in native coding In-Reply-To: <9258B546-0B8C-4EE3-BD92-3B3D642A77B1@oracle.com> References: <6383c30b9bd446ecb88a34cae9f5bd0e@derote13de46.global.corp.sap> <9258B546-0B8C-4EE3-BD92-3B3D642A77B1@oracle.com> Message-ID: <14839b244c064a69ac30d3492eb7ecf6@derote13de46.global.corp.sap> Thanks for reviewing. It's pushed: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/c8c1c19a4680 > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Dienstag, 14. Februar 2017 13:32 > To: Langer, Christoph > Cc: nio-dev at openjdk.java.net > Subject: Re: JDK10: RFR (S): 8174834: nio (ch): Remove #ifdef AF_INET6 > guards in native coding > > > > On 13 Feb 2017, at 16:28, Langer, Christoph > wrote: > > > > Hi, > > > > please review a small cleanup for JDK10. The #ifdef AF_INET6 sections can > be cleaned up in libnio native coding ? just as it was done for libnet already > (JDK-8168771). > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8174834 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8174834.0/ > > Looks good Christoph. > > -Chris. From brian.burkhalter at oracle.com Wed Feb 15 19:24:21 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 15 Feb 2017 11:24:21 -0800 Subject: JDK 9 RFR of 8175033: (se) Improve internal timing of java/nio/channels/Selector/WakeupAfterClose.java Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8175033 Patch: http://cr.openjdk.java.net/~bpb/8175033/webrev.00/ Improve the probability that the spawned thread will be blocked in select() before the main thread calls close() on the Selector thus hopefully averting the recurrence of [1]. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8143614 From brian.burkhalter at oracle.com Wed Feb 15 21:03:55 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 15 Feb 2017 13:03:55 -0800 Subject: JDK 9 RFR of 8175041: Add success message to java/nio/channels/FileChannel/LoopingTruncate.java Message-ID: <5FF97305-4047-42E6-9114-B06E3E776428@oracle.com> Please review this trivial fix [1] for [2]. The intent is to add to the test log evidence that the test in fact completed. Thanks, Brian [1] diff --- a/test/java/nio/channels/FileChannel/LoopingTruncate.java +++ b/test/java/nio/channels/FileChannel/LoopingTruncate.java @@ -76,5 +76,8 @@ } finally { Files.deleteIfExists(path); } + + System.out.println("Test succeeded."); + System.out.flush(); } } [2] https://bugs.openjdk.java.net/browse/JDK-8175041 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Feb 15 21:05:48 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2017 21:05:48 +0000 Subject: JDK 9 RFR of 8175041: Add success message to java/nio/channels/FileChannel/LoopingTruncate.java In-Reply-To: <5FF97305-4047-42E6-9114-B06E3E776428@oracle.com> References: <5FF97305-4047-42E6-9114-B06E3E776428@oracle.com> Message-ID: On 15/02/2017 21:03, Brian Burkhalter wrote: > Please review this trivial fix [1] for [2]. The intent is to add to > the test log evidence that the test in fact completed. Looks okay although not sure that it is needed. From brian.burkhalter at oracle.com Wed Feb 15 21:06:33 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 15 Feb 2017 13:06:33 -0800 Subject: JDK 9 RFR of 8175041: Add success message to java/nio/channels/FileChannel/LoopingTruncate.java In-Reply-To: References: <5FF97305-4047-42E6-9114-B06E3E776428@oracle.com> Message-ID: <1B35B13A-6A62-4168-B472-E228BD92068A@oracle.com> On Feb 15, 2017, at 1:05 PM, Alan Bateman wrote: > On 15/02/2017 21:03, Brian Burkhalter wrote: > >> Please review this trivial fix [1] for [2]. The intent is to add to the test log evidence that the test in fact completed. > Looks okay although not sure that it is needed. Probably not but I think no harm done. From Alan.Bateman at oracle.com Thu Feb 16 11:56:37 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Feb 2017 11:56:37 +0000 Subject: JDK 9 RFR of 8175033: (se) Improve internal timing of java/nio/channels/Selector/WakeupAfterClose.java In-Reply-To: References: Message-ID: <7f0e6bf3-c6f6-f8cc-c45e-3c3ddf4e4da7@oracle.com> On 15/02/2017 19:24, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8175033 > Patch: http://cr.openjdk.java.net/~bpb/8175033/webrev.00/ > > Improve the probability that the spawned thread will be blocked in select() before the main thread calls close() on the Selector thus hopefully averting the recurrence of [1]. > I'm not sure that I understand the bug report. The thread calling select will periodically throw ClosedSelectorException, that is normal as the Selector is closed asynchronously. It seems this is somehow reported by the main thread, is that right? I wonder if there is a previous test using an uncaught exception handler that is causing interference here. If so then I don't think the changes to the test in the patch will help. Can you instead change the test to catch the excepted ClosedSelectorException? -Alan From christoph.langer at sap.com Thu Feb 16 15:22:28 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 16 Feb 2017 15:22:28 +0000 Subject: rmid on Unix fails with Exception - maybe aftermath of JDK-8173607 ?? In-Reply-To: References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap> Message-ID: Hi Daniel, thanks for your hints - I should probably have seen that myself if I would have had a more thorough look... I'm cc-ing nio-dev, maybe somebody has an idea. I probably won't be able to analyze this short term. Best regards Christoph > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Sent: Donnerstag, 16. Februar 2017 15:53 > To: Langer, Christoph > Cc: Zeller, Arno ; Baesken, Matthias > ; core-libs-dev at openjdk.java.net > Subject: Re: rmid on Unix fails with Exception - maybe aftermath of JDK- > 8173607 ?? > > Hi Christoph, > > It looks like one of the dreaded class initialization cycle > issues. > > If you look at the stack trace, you will see that > UnixNativeDispatcher.:609 > calls System.loadLibrary at line 611 > which later down the road calls the > native UnixNativeDispatcher.getcwd command > from sun.nio.fs.UnixFileSystem. > > But at this point UnixNativeDispatcher has not > finished initializing: we're still trying to load > the nio lib... > > I don't think this has anything to do with JDK-8173607. > JDK-8173607 just splitted the JMX RMI Connector out of > java.management - and rmid has nothing to do with JMX. > > rmid doesn't depend on either java.management or > java.management.rmi, and I don't see anything > on the exception path that would involve either > of these modules. > So I suspect the culprit is probably elsewhere. > > best regards, > > -- daniel > > > > On 16/02/17 13:53, Langer, Christoph wrote: > > Hi Daniel, > > > > > > > > when starting "rmid" from current builds on Linux (and probably other > > Unix platforms as well) we are currently getting the exception below. > > > > > > > > It looks as if on that path libnio was not loaded and hence we're > > getting an UnsatisfiedLinkError. In UnixNativeDispatcher.java one can > > find a static initialization block which should do that, however, it > > needs elevated access. Maybe rmid is missing a permission for that? > > > > > > > > Any thoughts? > > > > > > > > Thanks & best regards > > > > Christoph > > > > > > > > > > > > ...>/jdk9-build-dir/images/jdk/bin/rmid > > > > Exception in thread "main" java.lang.UnsatisfiedLinkError: > > sun.nio.fs.UnixNativeDispatcher.getcwd()[B > > > > at java.base/sun.nio.fs.UnixNativeDispatcher.getcwd(Native Method) > > > > at > > java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:66) > > > > at > > java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) > > > > at > > > java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste > mProvider.java:46) > > > > at > > > java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste > mProvider.java:39) > > > > at > > > java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider. > java:56) > > > > at > > > java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvide > r.java:41) > > > > at > > > java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr > ovider.java:41) > > > > at > > java.base/java.io.FilePermission.(FilePermission.java:206) > > > > at > > > java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:899) > > > > at java.base/java.io.File.exists(File.java:815) > > > > at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2513) > > > > at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2510) > > > > at java.base/java.security.AccessController.doPrivileged(Native > > Method) > > > > at > > java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2509) > > > > at > > java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2478) > > > > at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873) > > > > at java.base/java.lang.System.loadLibrary(System.java:1818) > > > > at > > > java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java > :611) > > > > at > > > java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java > :609) > > > > at java.base/java.security.AccessController.doPrivileged(Native > > Method) > > > > at > > > java.base/sun.nio.fs.UnixNativeDispatcher.(UnixNativeDispatcher.jav > a:609) > > > > at > > java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:66) > > > > at > > java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) > > > > at > > > java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste > mProvider.java:46) > > > > at > > > java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste > mProvider.java:39) > > > > at > > > java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider. > java:56) > > > > at > > > java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvide > r.java:41) > > > > at > > > java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr > ovider.java:41) > > > > at java.base/java.nio.file.FileSystems.(FileSystems.java:91) > > > > at java.base/java.nio.file.Paths.get(Paths.java:84) > > > > at > > > java.base/jdk.internal.jimage.ImageReaderFactory.(ImageReaderFact > ory.java:50) > > > > at java.base/java.security.AccessController.doPrivileged(Native > > Method) > > > > at > > > java.base/sun.net.www.protocol.jrt.JavaRuntimeURLConnection.(Jav > aRuntimeURLConnection.java:59) > > > > at > > > java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java: > 42) > > > > at java.base/java.net.URL.openConnection(URL.java:1049) > > > > at > > > java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.c > heckPermissionToConnect(SystemModuleFinder.java:287) > > > > at > > > java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.< > init>(SystemModuleFinder.java:296) > > > > at > > > java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi > nder.java:245) > > > > at > > > java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi > nder.java:242) > > > > at > > > java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferen > ceImpl.java:83) > > > > at > > > java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(Builtin > ClassLoader.java:934) > > > > at > > > java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(Concu > rrentHashMap.java:1719) > > > > at > > > java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinCla > ssLoader.java:926) > > > > at > > > java.base/jdk.internal.loader.BuiltinClassLoader.access$100(BuiltinClassLoad > er.java:92) > > > > at > > > java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav > a:356) > > > > at > > > java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav > a:351) > > > > at java.base/java.security.AccessController.doPrivileged(Native > > Method) > > > > at > > > java.base/jdk.internal.loader.BuiltinClassLoader.findMiscResource(BuiltinCla > ssLoader.java:350) > > > > at > > > java.base/jdk.internal.loader.BuiltinClassLoader.findResources(BuiltinClassLo > ader.java:311) > > > > at > > > java.base/jdk.internal.loader.BootLoader.findResources(BootLoader.java:15 > 6) > > > > at > > java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1430) > > > > at > > java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1428) > > > > at > > > java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextServi > ce(ServiceLoader.java:1082) > > > > at > > > java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.access$1200( > ServiceLoader.java:1004) > > > > at > > > java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic > eLoader.java:1131) > > > > at > > > java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic > eLoader.java:1130) > > > > at java.base/java.security.AccessController.doPrivileged(Native > > Method) > > > > at > > > java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Ser > viceLoader.java:1133) > > > > at > > java.base/java.util.ServiceLoader$1.hasNext(ServiceLoader.java:1163) > > > > at > > java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1258) > > > > at > > > java.base/java.nio.channels.spi.SelectorProvider.loadProviderAsService(Sele > ctorProvider.java:122) > > > > at > > > java.base/java.nio.channels.spi.SelectorProvider.access$200(SelectorProvide > r.java:69) > > > > at > > > java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav > a:180) > > > > at > > > java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav > a:176) > > > > at java.base/java.security.AccessController.doPrivileged(Native > > Method) > > > > at > > > java.base/java.nio.channels.spi.SelectorProvider.provider(SelectorProvider.j > ava:175) > > > > at java.base/java.lang.System.inheritedChannel(System.java:276) > > > > at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1960) > > > > at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1958) > > > > at java.base/java.security.AccessController.doPrivileged(Native > > Method) > > > > at java.rmi/sun.rmi.server.Activation.main(Activation.java:1957) > > > > > > From daniel.fuchs at oracle.com Thu Feb 16 16:02:15 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 16 Feb 2017 16:02:15 +0000 Subject: rmid on Unix fails with Exception - maybe aftermath of JDK-8173607 ?? In-Reply-To: References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap> Message-ID: <8d01d5b9-56a4-af3a-8336-ce123235619c@oracle.com> On 16/02/17 15:22, Langer, Christoph wrote: > Hi Daniel, > > thanks for your hints - I should probably have seen that myself if I would have had a more thorough look... > > I'm cc-ing nio-dev, maybe somebody has an idea. I probably won't be able to analyze this short term. No problem. Do you know when that started showing up? best regards, -- daniel > > Best regards > Christoph > >> -----Original Message----- >> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] >> Sent: Donnerstag, 16. Februar 2017 15:53 >> To: Langer, Christoph >> Cc: Zeller, Arno ; Baesken, Matthias >> ; core-libs-dev at openjdk.java.net >> Subject: Re: rmid on Unix fails with Exception - maybe aftermath of JDK- >> 8173607 ?? >> >> Hi Christoph, >> >> It looks like one of the dreaded class initialization cycle >> issues. >> >> If you look at the stack trace, you will see that >> UnixNativeDispatcher.:609 >> calls System.loadLibrary at line 611 >> which later down the road calls the >> native UnixNativeDispatcher.getcwd command >> from sun.nio.fs.UnixFileSystem. >> >> But at this point UnixNativeDispatcher has not >> finished initializing: we're still trying to load >> the nio lib... >> >> I don't think this has anything to do with JDK-8173607. >> JDK-8173607 just splitted the JMX RMI Connector out of >> java.management - and rmid has nothing to do with JMX. >> >> rmid doesn't depend on either java.management or >> java.management.rmi, and I don't see anything >> on the exception path that would involve either >> of these modules. >> So I suspect the culprit is probably elsewhere. >> >> best regards, >> >> -- daniel >> >> >> >> On 16/02/17 13:53, Langer, Christoph wrote: >>> Hi Daniel, >>> >>> >>> >>> when starting "rmid" from current builds on Linux (and probably other >>> Unix platforms as well) we are currently getting the exception below. >>> >>> >>> >>> It looks as if on that path libnio was not loaded and hence we're >>> getting an UnsatisfiedLinkError. In UnixNativeDispatcher.java one can >>> find a static initialization block which should do that, however, it >>> needs elevated access. Maybe rmid is missing a permission for that? >>> >>> >>> >>> Any thoughts? >>> >>> >>> >>> Thanks & best regards >>> >>> Christoph >>> >>> >>> >>> >>> >>> ...>/jdk9-build-dir/images/jdk/bin/rmid >>> >>> Exception in thread "main" java.lang.UnsatisfiedLinkError: >>> sun.nio.fs.UnixNativeDispatcher.getcwd()[B >>> >>> at java.base/sun.nio.fs.UnixNativeDispatcher.getcwd(Native Method) >>> >>> at >>> java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:66) >>> >>> at >>> java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) >>> >>> at >>> >> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste >> mProvider.java:46) >>> >>> at >>> >> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste >> mProvider.java:39) >>> >>> at >>> >> java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider. >> java:56) >>> >>> at >>> >> java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvide >> r.java:41) >>> >>> at >>> >> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr >> ovider.java:41) >>> >>> at >>> java.base/java.io.FilePermission.(FilePermission.java:206) >>> >>> at >>> >> java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:899) >>> >>> at java.base/java.io.File.exists(File.java:815) >>> >>> at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2513) >>> >>> at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2510) >>> >>> at java.base/java.security.AccessController.doPrivileged(Native >>> Method) >>> >>> at >>> java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2509) >>> >>> at >>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2478) >>> >>> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873) >>> >>> at java.base/java.lang.System.loadLibrary(System.java:1818) >>> >>> at >>> >> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java >> :611) >>> >>> at >>> >> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java >> :609) >>> >>> at java.base/java.security.AccessController.doPrivileged(Native >>> Method) >>> >>> at >>> >> java.base/sun.nio.fs.UnixNativeDispatcher.(UnixNativeDispatcher.jav >> a:609) >>> >>> at >>> java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:66) >>> >>> at >>> java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) >>> >>> at >>> >> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste >> mProvider.java:46) >>> >>> at >>> >> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste >> mProvider.java:39) >>> >>> at >>> >> java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider. >> java:56) >>> >>> at >>> >> java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvide >> r.java:41) >>> >>> at >>> >> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr >> ovider.java:41) >>> >>> at java.base/java.nio.file.FileSystems.(FileSystems.java:91) >>> >>> at java.base/java.nio.file.Paths.get(Paths.java:84) >>> >>> at >>> >> java.base/jdk.internal.jimage.ImageReaderFactory.(ImageReaderFact >> ory.java:50) >>> >>> at java.base/java.security.AccessController.doPrivileged(Native >>> Method) >>> >>> at >>> >> java.base/sun.net.www.protocol.jrt.JavaRuntimeURLConnection.(Jav >> aRuntimeURLConnection.java:59) >>> >>> at >>> >> java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java: >> 42) >>> >>> at java.base/java.net.URL.openConnection(URL.java:1049) >>> >>> at >>> >> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.c >> heckPermissionToConnect(SystemModuleFinder.java:287) >>> >>> at >>> >> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.< >> init>(SystemModuleFinder.java:296) >>> >>> at >>> >> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi >> nder.java:245) >>> >>> at >>> >> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi >> nder.java:242) >>> >>> at >>> >> java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferen >> ceImpl.java:83) >>> >>> at >>> >> java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(Builtin >> ClassLoader.java:934) >>> >>> at >>> >> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(Concu >> rrentHashMap.java:1719) >>> >>> at >>> >> java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinCla >> ssLoader.java:926) >>> >>> at >>> >> java.base/jdk.internal.loader.BuiltinClassLoader.access$100(BuiltinClassLoad >> er.java:92) >>> >>> at >>> >> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav >> a:356) >>> >>> at >>> >> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav >> a:351) >>> >>> at java.base/java.security.AccessController.doPrivileged(Native >>> Method) >>> >>> at >>> >> java.base/jdk.internal.loader.BuiltinClassLoader.findMiscResource(BuiltinCla >> ssLoader.java:350) >>> >>> at >>> >> java.base/jdk.internal.loader.BuiltinClassLoader.findResources(BuiltinClassLo >> ader.java:311) >>> >>> at >>> >> java.base/jdk.internal.loader.BootLoader.findResources(BootLoader.java:15 >> 6) >>> >>> at >>> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1430) >>> >>> at >>> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1428) >>> >>> at >>> >> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextServi >> ce(ServiceLoader.java:1082) >>> >>> at >>> >> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.access$1200( >> ServiceLoader.java:1004) >>> >>> at >>> >> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic >> eLoader.java:1131) >>> >>> at >>> >> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic >> eLoader.java:1130) >>> >>> at java.base/java.security.AccessController.doPrivileged(Native >>> Method) >>> >>> at >>> >> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Ser >> viceLoader.java:1133) >>> >>> at >>> java.base/java.util.ServiceLoader$1.hasNext(ServiceLoader.java:1163) >>> >>> at >>> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1258) >>> >>> at >>> >> java.base/java.nio.channels.spi.SelectorProvider.loadProviderAsService(Sele >> ctorProvider.java:122) >>> >>> at >>> >> java.base/java.nio.channels.spi.SelectorProvider.access$200(SelectorProvide >> r.java:69) >>> >>> at >>> >> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav >> a:180) >>> >>> at >>> >> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav >> a:176) >>> >>> at java.base/java.security.AccessController.doPrivileged(Native >>> Method) >>> >>> at >>> >> java.base/java.nio.channels.spi.SelectorProvider.provider(SelectorProvider.j >> ava:175) >>> >>> at java.base/java.lang.System.inheritedChannel(System.java:276) >>> >>> at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1960) >>> >>> at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1958) >>> >>> at java.base/java.security.AccessController.doPrivileged(Native >>> Method) >>> >>> at java.rmi/sun.rmi.server.Activation.main(Activation.java:1957) >>> >>> >>> > From christoph.langer at sap.com Thu Feb 16 16:03:48 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 16 Feb 2017 16:03:48 +0000 Subject: rmid on Unix fails with Exception - maybe aftermath of JDK-8173607 ?? In-Reply-To: <8d01d5b9-56a4-af3a-8336-ce123235619c@oracle.com> References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap> <8d01d5b9-56a4-af3a-8336-ce123235619c@oracle.com> Message-ID: The colleagues tell me that it was about two weeks ago. But I guess it's rather a felt experience than a concrete date ;-) > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Sent: Donnerstag, 16. Februar 2017 17:02 > To: Langer, Christoph ; nio- > dev at openjdk.java.net > Cc: Zeller, Arno ; Baesken, Matthias > ; core-libs-dev at openjdk.java.net > Subject: Re: rmid on Unix fails with Exception - maybe aftermath of JDK- > 8173607 ?? > > On 16/02/17 15:22, Langer, Christoph wrote: > > Hi Daniel, > > > > thanks for your hints - I should probably have seen that myself if I would > have had a more thorough look... > > > > I'm cc-ing nio-dev, maybe somebody has an idea. I probably won't be able > to analyze this short term. > > No problem. Do you know when that started showing up? > > best regards, > > -- daniel > > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > >> Sent: Donnerstag, 16. Februar 2017 15:53 > >> To: Langer, Christoph > >> Cc: Zeller, Arno ; Baesken, Matthias > >> ; core-libs-dev at openjdk.java.net > >> Subject: Re: rmid on Unix fails with Exception - maybe aftermath of JDK- > >> 8173607 ?? > >> > >> Hi Christoph, > >> > >> It looks like one of the dreaded class initialization cycle > >> issues. > >> > >> If you look at the stack trace, you will see that > >> UnixNativeDispatcher.:609 > >> calls System.loadLibrary at line 611 > >> which later down the road calls the > >> native UnixNativeDispatcher.getcwd command > >> from sun.nio.fs.UnixFileSystem. > >> > >> But at this point UnixNativeDispatcher has not > >> finished initializing: we're still trying to load > >> the nio lib... > >> > >> I don't think this has anything to do with JDK-8173607. > >> JDK-8173607 just splitted the JMX RMI Connector out of > >> java.management - and rmid has nothing to do with JMX. > >> > >> rmid doesn't depend on either java.management or > >> java.management.rmi, and I don't see anything > >> on the exception path that would involve either > >> of these modules. > >> So I suspect the culprit is probably elsewhere. > >> > >> best regards, > >> > >> -- daniel > >> > >> > >> > >> On 16/02/17 13:53, Langer, Christoph wrote: > >>> Hi Daniel, > >>> > >>> > >>> > >>> when starting "rmid" from current builds on Linux (and probably other > >>> Unix platforms as well) we are currently getting the exception below. > >>> > >>> > >>> > >>> It looks as if on that path libnio was not loaded and hence we're > >>> getting an UnsatisfiedLinkError. In UnixNativeDispatcher.java one can > >>> find a static initialization block which should do that, however, it > >>> needs elevated access. Maybe rmid is missing a permission for that? > >>> > >>> > >>> > >>> Any thoughts? > >>> > >>> > >>> > >>> Thanks & best regards > >>> > >>> Christoph > >>> > >>> > >>> > >>> > >>> > >>> ...>/jdk9-build-dir/images/jdk/bin/rmid > >>> > >>> Exception in thread "main" java.lang.UnsatisfiedLinkError: > >>> sun.nio.fs.UnixNativeDispatcher.getcwd()[B > >>> > >>> at java.base/sun.nio.fs.UnixNativeDispatcher.getcwd(Native > Method) > >>> > >>> at > >>> java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:66) > >>> > >>> at > >>> java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste > >> mProvider.java:46) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste > >> mProvider.java:39) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider. > >> java:56) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvide > >> r.java:41) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr > >> ovider.java:41) > >>> > >>> at > >>> java.base/java.io.FilePermission.(FilePermission.java:206) > >>> > >>> at > >>> > >> > java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:899) > >>> > >>> at java.base/java.io.File.exists(File.java:815) > >>> > >>> at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2513) > >>> > >>> at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2510) > >>> > >>> at java.base/java.security.AccessController.doPrivileged(Native > >>> Method) > >>> > >>> at > >>> java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2509) > >>> > >>> at > >>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2478) > >>> > >>> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873) > >>> > >>> at java.base/java.lang.System.loadLibrary(System.java:1818) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java > >> :611) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java > >> :609) > >>> > >>> at java.base/java.security.AccessController.doPrivileged(Native > >>> Method) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.UnixNativeDispatcher.(UnixNativeDispatcher.jav > >> a:609) > >>> > >>> at > >>> java.base/sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:66) > >>> > >>> at > >>> java.base/sun.nio.fs.LinuxFileSystem.(LinuxFileSystem.java:39) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste > >> mProvider.java:46) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste > >> mProvider.java:39) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.UnixFileSystemProvider.(UnixFileSystemProvider. > >> java:56) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.LinuxFileSystemProvider.(LinuxFileSystemProvide > >> r.java:41) > >>> > >>> at > >>> > >> > java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr > >> ovider.java:41) > >>> > >>> at java.base/java.nio.file.FileSystems.(FileSystems.java:91) > >>> > >>> at java.base/java.nio.file.Paths.get(Paths.java:84) > >>> > >>> at > >>> > >> > java.base/jdk.internal.jimage.ImageReaderFactory.(ImageReaderFact > >> ory.java:50) > >>> > >>> at java.base/java.security.AccessController.doPrivileged(Native > >>> Method) > >>> > >>> at > >>> > >> > java.base/sun.net.www.protocol.jrt.JavaRuntimeURLConnection.(Jav > >> aRuntimeURLConnection.java:59) > >>> > >>> at > >>> > >> > java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java: > >> 42) > >>> > >>> at java.base/java.net.URL.openConnection(URL.java:1049) > >>> > >>> at > >>> > >> > java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.c > >> heckPermissionToConnect(SystemModuleFinder.java:287) > >>> > >>> at > >>> > >> > java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.< > >> init>(SystemModuleFinder.java:296) > >>> > >>> at > >>> > >> > java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi > >> nder.java:245) > >>> > >>> at > >>> > >> > java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi > >> nder.java:242) > >>> > >>> at > >>> > >> > java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferen > >> ceImpl.java:83) > >>> > >>> at > >>> > >> > java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(Builtin > >> ClassLoader.java:934) > >>> > >>> at > >>> > >> > java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(Concu > >> rrentHashMap.java:1719) > >>> > >>> at > >>> > >> > java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinCla > >> ssLoader.java:926) > >>> > >>> at > >>> > >> > java.base/jdk.internal.loader.BuiltinClassLoader.access$100(BuiltinClassLoad > >> er.java:92) > >>> > >>> at > >>> > >> > java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav > >> a:356) > >>> > >>> at > >>> > >> > java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav > >> a:351) > >>> > >>> at java.base/java.security.AccessController.doPrivileged(Native > >>> Method) > >>> > >>> at > >>> > >> > java.base/jdk.internal.loader.BuiltinClassLoader.findMiscResource(BuiltinCla > >> ssLoader.java:350) > >>> > >>> at > >>> > >> > java.base/jdk.internal.loader.BuiltinClassLoader.findResources(BuiltinClassLo > >> ader.java:311) > >>> > >>> at > >>> > >> > java.base/jdk.internal.loader.BootLoader.findResources(BootLoader.java:15 > >> 6) > >>> > >>> at > >>> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1430) > >>> > >>> at > >>> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1428) > >>> > >>> at > >>> > >> > java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextServi > >> ce(ServiceLoader.java:1082) > >>> > >>> at > >>> > >> > java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.access$1200( > >> ServiceLoader.java:1004) > >>> > >>> at > >>> > >> > java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic > >> eLoader.java:1131) > >>> > >>> at > >>> > >> > java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic > >> eLoader.java:1130) > >>> > >>> at java.base/java.security.AccessController.doPrivileged(Native > >>> Method) > >>> > >>> at > >>> > >> > java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Ser > >> viceLoader.java:1133) > >>> > >>> at > >>> java.base/java.util.ServiceLoader$1.hasNext(ServiceLoader.java:1163) > >>> > >>> at > >>> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1258) > >>> > >>> at > >>> > >> > java.base/java.nio.channels.spi.SelectorProvider.loadProviderAsService(Sele > >> ctorProvider.java:122) > >>> > >>> at > >>> > >> > java.base/java.nio.channels.spi.SelectorProvider.access$200(SelectorProvide > >> r.java:69) > >>> > >>> at > >>> > >> > java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav > >> a:180) > >>> > >>> at > >>> > >> > java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav > >> a:176) > >>> > >>> at java.base/java.security.AccessController.doPrivileged(Native > >>> Method) > >>> > >>> at > >>> > >> > java.base/java.nio.channels.spi.SelectorProvider.provider(SelectorProvider.j > >> ava:175) > >>> > >>> at java.base/java.lang.System.inheritedChannel(System.java:276) > >>> > >>> at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1960) > >>> > >>> at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1958) > >>> > >>> at java.base/java.security.AccessController.doPrivileged(Native > >>> Method) > >>> > >>> at java.rmi/sun.rmi.server.Activation.main(Activation.java:1957) > >>> > >>> > >>> > > From brian.burkhalter at oracle.com Thu Feb 16 19:09:46 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 16 Feb 2017 11:09:46 -0800 Subject: JDK 9 RFR of 8175033: (se) Improve internal timing of java/nio/channels/Selector/WakeupAfterClose.java In-Reply-To: <7f0e6bf3-c6f6-f8cc-c45e-3c3ddf4e4da7@oracle.com> References: <7f0e6bf3-c6f6-f8cc-c45e-3c3ddf4e4da7@oracle.com> Message-ID: <821255A3-8250-4FE7-8243-1AFB53D38480@oracle.com> On Feb 16, 2017, at 3:56 AM, Alan Bateman wrote: > I don't think the changes to the test in the patch will help. Can you instead change the test to catch the excepted ClosedSelectorException? Please see http://cr.openjdk.java.net/~bpb/8175033/webrev.01/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 16 19:15:03 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Feb 2017 19:15:03 +0000 Subject: JDK 9 RFR of 8175033: (se) Improve internal timing of java/nio/channels/Selector/WakeupAfterClose.java In-Reply-To: <821255A3-8250-4FE7-8243-1AFB53D38480@oracle.com> References: <7f0e6bf3-c6f6-f8cc-c45e-3c3ddf4e4da7@oracle.com> <821255A3-8250-4FE7-8243-1AFB53D38480@oracle.com> Message-ID: On 16/02/2017 19:09, Brian Burkhalter wrote: > On Feb 16, 2017, at 3:56 AM, Alan Bateman > wrote: > >> I don't think the changes to the test in the patch will help. Can you >> instead change the test to catch the excepted ClosedSelectorException? > > Please see http://cr.openjdk.java.net/~bpb/8175033/webrev.01/ > > Looks okay although it might be better to printed for ClosedSelectorException to make it clear in the logs that it is expected. If we have other sightings of this then we'll know it's something completely different. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 16 20:12:45 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 16 Feb 2017 12:12:45 -0800 Subject: JDK 9 RFR of 8175033: (se) Improve internal timing of java/nio/channels/Selector/WakeupAfterClose.java In-Reply-To: References: <7f0e6bf3-c6f6-f8cc-c45e-3c3ddf4e4da7@oracle.com> <821255A3-8250-4FE7-8243-1AFB53D38480@oracle.com> Message-ID: On Feb 16, 2017, at 11:15 AM, Alan Bateman wrote: > Looks okay although it might be better to printed for ClosedSelectorException to make it clear in the logs that it is expected. If we have other sightings of this then we'll know it's something completely different. OK here?s one more version: http://cr.openjdk.java.net/~bpb/8175033/webrev.02/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 16 20:15:31 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Feb 2017 20:15:31 +0000 Subject: JDK 9 RFR of 8175033: (se) Improve internal timing of java/nio/channels/Selector/WakeupAfterClose.java In-Reply-To: References: <7f0e6bf3-c6f6-f8cc-c45e-3c3ddf4e4da7@oracle.com> <821255A3-8250-4FE7-8243-1AFB53D38480@oracle.com> Message-ID: <281600c1-c6ec-0b27-3de1-f443d2ac3a87@oracle.com> On 16/02/2017 20:12, Brian Burkhalter wrote: > > On Feb 16, 2017, at 11:15 AM, Alan Bateman > wrote: > >> Looks okay although it might be better to printed for >> ClosedSelectorException to make it clear in the logs that it is >> expected. If we have other sightings of this then we'll know it's >> something completely different. > > OK here?s one more version: > > http://cr.openjdk.java.net/~bpb/8175033/webrev.02/ > > > Looks okay. Good luck with this hunt. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 16 22:47:48 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 16 Feb 2017 14:47:48 -0800 Subject: JDK 9 RFR of JDK-8175062: Mark java/nio/channels/AsyncCloseAndInterrupt.java as intermittently failing In-Reply-To: <0b341bb0-83c0-addd-b425-a4c94e470551@oracle.com> References: <0b341bb0-83c0-addd-b425-a4c94e470551@oracle.com> Message-ID: [Re-directing to nio-dev] Looks OK. Thanks, Brian On Feb 15, 2017, at 11:10 PM, Amy Lu wrote: > java/nio/channels/AsyncCloseAndInterrupt.java > > This test is known to fail intermittently (JDK-8172045), this patch is to mark the test accordingly with keyword 'intermittent'. > > Please review. > > bug: https://bugs.openjdk.java.net/browse/JDK-8175062 > webrev: http://cr.openjdk.java.net/~amlu/8175062/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 17 01:48:28 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 16 Feb 2017 17:48:28 -0800 Subject: JDK 9 RFR of 8175115: Improve instrumentation of java/nio/file/WatchService/LotsOfEvents.java Message-ID: Please review this test-only change at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8175115 Patch: http://cr.openjdk.java.net/~bpb/8175115/webrev.00/ In case of detecting an insufficient number of file creation or deletion events, attempt one more long polling of the WatchService to see whether more events might be detected given a longer timeout, and print extra information about the number of events detected versus expected, and the number of existing files. Thanks, Brian From brian.burkhalter at oracle.com Fri Feb 24 18:45:10 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 24 Feb 2017 10:45:10 -0800 Subject: Fwd: JDK 9 RFR of 8175115: Improve instrumentation of java/nio/file/WatchService/LotsOfEvents.java References: Message-ID: <9C9080CE-690E-496A-8EA2-3606AFD5DD14@oracle.com> Ping! Begin forwarded message: > From: Brian Burkhalter > Subject: JDK 9 RFR of 8175115: Improve instrumentation of java/nio/file/WatchService/LotsOfEvents.java > Date: February 16, 2017 at 5:48:28 PM PST > To: nio-dev > > Please review this test-only change at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8175115 > Patch: http://cr.openjdk.java.net/~bpb/8175115/webrev.00/ > > In case of detecting an insufficient number of file creation or deletion events, attempt one more long polling of the WatchService to see whether more events might be detected given a longer timeout, and print extra information about the number of events detected versus expected, and the number of existing files. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Fri Feb 24 18:59:32 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 24 Feb 2017 13:59:32 -0500 Subject: Fwd: JDK 9 RFR of 8175115: Improve instrumentation of java/nio/file/WatchService/LotsOfEvents.java In-Reply-To: <9C9080CE-690E-496A-8EA2-3606AFD5DD14@oracle.com> References: <9C9080CE-690E-496A-8EA2-3606AFD5DD14@oracle.com> Message-ID: <10c00f91-d9db-1a2b-b7cc-954d00f28306@Oracle.com> Hi Brian, The new diagnostics look fine. It might be interesting to know how long it takes for the extra events to show up; if they show up. Roger On 2/24/2017 1:45 PM, Brian Burkhalter wrote: > Ping! > > Begin forwarded message: > >> *From: *Brian Burkhalter > > >> *Subject: **JDK 9 RFR of 8175115: Improve instrumentation of >> java/nio/file/WatchService/LotsOfEvents.java* >> *Date: *February 16, 2017 at 5:48:28 PM PST >> *To: *nio-dev > > >> >> Please review this test-only change at your convenience. >> >> Issue:https://bugs.openjdk.java.net/browse/JDK-8175115 >> Patch:http://cr.openjdk.java.net/~bpb/8175115/webrev.00/ >> >> In case of detecting an insufficient number of file creation or >> deletion events, attempt one more long polling of the WatchService to >> see whether more events might be detected given a longer timeout, and >> print extra information about the number of events detected versus >> expected, and the number of existing files. >> >> Thanks, >> >> Brian > From brian.burkhalter at oracle.com Fri Feb 24 19:32:19 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 24 Feb 2017 11:32:19 -0800 Subject: JDK 9 RFR of 8175115: Improve instrumentation of java/nio/file/WatchService/LotsOfEvents.java In-Reply-To: <10c00f91-d9db-1a2b-b7cc-954d00f28306@Oracle.com> References: <9C9080CE-690E-496A-8EA2-3606AFD5DD14@oracle.com> <10c00f91-d9db-1a2b-b7cc-954d00f28306@Oracle.com> Message-ID: <3F4AC20E-D769-4CCD-AC16-5CA1E2872226@oracle.com> Hi Roger, On Feb 24, 2017, at 10:59 AM, Roger Riggs wrote: > The new diagnostics look fine. Thanks for the review. > It might be interesting to know how long it takes for the extra events to show up; > if they show up. Good suggestion. I?ve updated the patch http://cr.openjdk.java.net/~bpb/8175115/webrev.01/ at lines 134, 136, 141-142 (new version). Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Fri Feb 24 19:33:35 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 24 Feb 2017 14:33:35 -0500 Subject: JDK 9 RFR of 8175115: Improve instrumentation of java/nio/file/WatchService/LotsOfEvents.java In-Reply-To: <3F4AC20E-D769-4CCD-AC16-5CA1E2872226@oracle.com> References: <9C9080CE-690E-496A-8EA2-3606AFD5DD14@oracle.com> <10c00f91-d9db-1a2b-b7cc-954d00f28306@Oracle.com> <3F4AC20E-D769-4CCD-AC16-5CA1E2872226@oracle.com> Message-ID: <6185a006-5002-0b8d-bb74-1642ca4b4122@Oracle.com> +1 On 2/24/2017 2:32 PM, Brian Burkhalter wrote: > Hi Roger, > > On Feb 24, 2017, at 10:59 AM, Roger Riggs > wrote: > >> The new diagnostics look fine. > > Thanks for the review. > >> It might be interesting to know how long it takes for the extra >> events to show up; >> if they show up. > > Good suggestion. I?ve updated the patch > http://cr.openjdk.java.net/~bpb/8175115/webrev.01/ > at lines 134, > 136, 141-142 (new version). > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Feb 28 16:25:21 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 28 Feb 2017 08:25:21 -0800 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java Message-ID: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> Please review this test bug fix at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8175209 Patch: http://cr.openjdk.java.net/~bpb/8175209/webrev.00/ This test was failing due to a WritePendingException not occurring when expected. This is presumably due to the writes in the sequence of chained writes on the channel still being completed immediately despite the 5 second wait for the socket buffer to fill. When the writes are immediate there is a tiny time slice between when the channel is re-enabled for writing and when the handler is invoked. If the call to the write which is supposed to provoke the WritePendingException happens to occur in this small time window the exception will not be thrown and the test will fail. The change here is to record the most recent time at which CompletionHandler.completed() has been called and pause repeatedly until this time no longer changes. With this change the test passes on all platforms and is slightly faster as the total time paused is 2-3 seconds instead of 5. Assuming this fix is good, likely [1] will no longer occur and may eventually be resolved. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8161991 From brian.burkhalter at oracle.com Tue Feb 28 21:15:06 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 28 Feb 2017 13:15:06 -0800 Subject: JDK 9 RFR of 8175209: Account for race condition in java/nio/channels/AsynchronousSocketChannel/Basic.java In-Reply-To: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> References: <0E185973-3FB5-4FD3-B916-3A2030E7C521@oracle.com> Message-ID: Improved version which counts the number of invocations of CompletionHandler.completed() instead of tracking the time of the most recent invocation: http://cr.openjdk.java.net/~bpb/8175209/webrev.01/ Also delete unused variable t0. Thanks, Brian On Feb 28, 2017, at 8:25 AM, Brian Burkhalter wrote: > Please review this test bug fix at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8175209 > Patch: http://cr.openjdk.java.net/~bpb/8175209/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Feb 28 22:43:22 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 28 Feb 2017 14:43:22 -0800 Subject: RFC on java/nio/channels/FileChannel/InterruptDeadlock.java Message-ID: <0C3BD6AD-449D-4639-AE69-95A695F2EEF1@oracle.com> I don?t know whether [1] could be related to this, but it looks to me as if the test InterruptDeadlock.java is incorrect at line 61 [2]. It appears that the value of pos will reach fc.size() which is 1024*1024 + 1 and remain there for all subsequent iterations of the loop in which case fc.read() at line 57 would no longer read any bytes. It seems that the greater-than (>) at line 61 should instead be greater-than-or-equal (>=). This would be consistent with the specification of FileChannel.read(ByteBuffer,long) [3] which states that it will return -1 if the position is greater than or equal to the file?s current size. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8151862 [2] http://hg.openjdk.java.net/jdk9/dev/jdk/file/49b54a4d9e84/test/java/nio/channels/FileChannel/InterruptDeadlock.java#l51 [3] http://download.java.net/java/jdk9/docs/api/java/nio/channels/FileChannel.html#read-java.nio.ByteBuffer-long-