From brian.burkhalter at oracle.com Mon Aug 1 22:11:39 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 1 Aug 2016 15:11:39 -0700 Subject: JDK 9 RFR of 8146215: (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently on Solaris-sparc with Unexpected type: text/plain In-Reply-To: <96fab9bc-0afc-59a2-6da1-0a238bcd815a@oracle.com> References: <607BC614-DFBE-49B2-AA6D-5A01EFF21D56@oracle.com> <1C814958-7FA4-4F7A-BA69-E698EBE7AAD2@oracle.com> <07BA34F1-F454-4D2C-91CE-7698A65B0902@oracle.com> <96fab9bc-0afc-59a2-6da1-0a238bcd815a@oracle.com> Message-ID: On Jul 30, 2016, at 2:31 AM, Alan Bateman wrote: > The synchronization doesn't look right in FileNameMapFileTypeDetector. As fileNameMap is static then synchronized (this) { ... } doesn't do what you intend. Thanks, that was a mistake in creating this class from the code of the previous NetFileTypeDetector class. > It's not an issue if URLConnection.getFileNameMap() is invoked more than once so I think you can reduce this down to: > > FileNameMap map = fileNameMap; > if (map == null) { > fileNameMap = map = URLConnection.getFileNameMap(); > } > return map.getContentTypeFor(?); Modified accordingly: http://cr.openjdk.java.net/~bpb/8146215/webrev.02/ > Alternatively just call URLConnection.getFileNameMap() each time. URLConnection.getFileNameMap() is synchronized and returns a new anonymous class instance at each invocation so this does not look to be a good idea. > As regards ordering what what you have it okay. I assume it will be rare to set the property content.types.user.table and so the JDK's content-types.properties will be a fallback. Question is whether this should be a fallback on OS X and Windows as well. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Aug 2 01:40:39 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 1 Aug 2016 18:40:39 -0700 Subject: JDK 9 RFR of 8162902: Add some debugging output to test/java/nio/file/WatchService/DeleteInterference Message-ID: <1E5B9BDE-43F4-4CFB-A4D5-8E5707CD0194@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8162902 Patch: http://cr.openjdk.java.net/~bpb/8162902/webrev.00/ Add a few printfs to see whether this can help bracket the problem described in the parent task. Thanks, Brian From Roger.Riggs at Oracle.com Tue Aug 2 14:21:07 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 2 Aug 2016 10:21:07 -0400 Subject: JDK 9 RFR of 8146215: (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently on Solaris-sparc with Unexpected type: text/plain In-Reply-To: References: <607BC614-DFBE-49B2-AA6D-5A01EFF21D56@oracle.com> <1C814958-7FA4-4F7A-BA69-E698EBE7AAD2@oracle.com> <07BA34F1-F454-4D2C-91CE-7698A65B0902@oracle.com> <96fab9bc-0afc-59a2-6da1-0a238bcd815a@oracle.com> Message-ID: <18877efa-abb0-ab59-cce9-ea268a6b5a87@Oracle.com> Hi Brian, +1 Basic.java: Line 69: (pre-existing) Its probably useful to include the message from the exception, it may provide some clue as to what the problem was. On 8/1/2016 6:11 PM, Brian Burkhalter wrote: > On Jul 30, 2016, at 2:31 AM, Alan Bateman > wrote: > >> The synchronization doesn't look right in >> FileNameMapFileTypeDetector. As fileNameMap is static then >> synchronized (this) { ... } doesn't do what you intend. > > Thanks, that was a mistake in creating this class from the code of the > previous NetFileTypeDetector class. > >> It's not an issue if URLConnection.getFileNameMap() is invoked more >> than once so I think you can reduce this down to: >> >> FileNameMap map = fileNameMap; >> if (map == null) { >> fileNameMap = map = URLConnection.getFileNameMap(); >> } >> return map.getContentTypeFor(?); > > Modified accordingly: > http://cr.openjdk.java.net/~bpb/8146215/webrev.02/ > > >> Alternatively just call URLConnection.getFileNameMap() each time. > > URLConnection.getFileNameMap() is synchronized and returns a new > anonymous class instance at each invocation so this does not look to > be a good idea. > >> As regards ordering what what you have it okay. I assume it will be >> rare to set the property content.types.user.table and so the JDK's >> content-types.properties will be a fallback. > > Question is whether this should be a fallback on OS X and Windows as well. +1 that would provide a consistent cross-platform fallback based on the system property "content.types.user.table". Roger > > Thanks, > > Brian From Alan.Bateman at oracle.com Tue Aug 2 14:36:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Aug 2016 07:36:03 -0700 Subject: JDK 9 RFR of 8146215: (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently on Solaris-sparc with Unexpected type: text/plain In-Reply-To: References: <607BC614-DFBE-49B2-AA6D-5A01EFF21D56@oracle.com> <1C814958-7FA4-4F7A-BA69-E698EBE7AAD2@oracle.com> <07BA34F1-F454-4D2C-91CE-7698A65B0902@oracle.com> <96fab9bc-0afc-59a2-6da1-0a238bcd815a@oracle.com> Message-ID: On 01/08/2016 15:11, Brian Burkhalter wrote: > > Modified accordingly: > http://cr.openjdk.java.net/~bpb/8146215/webrev.02/ > There is a still a volatile write to initialize fileNameMap to null at L38, this can be removed. > >> Alternatively just call URLConnection.getFileNameMap() each time. > > URLConnection.getFileNameMap() is synchronized and returns a new > anonymous class instance at each invocation so this does not look to > be a good idea. I meant that we clean-up URLConnection.getFileNameMap(). > >> As regards ordering what what you have it okay. I assume it will be >> rare to set the property content.types.user.table and so the JDK's >> content-types.properties will be a fallback. > > Question is whether this should be a fallback on OS X and Windows as well. > On Windows then it's configured via the UI (backed by the registry) so probably not needed. On OSX then then can the mappings that the UTI based detector uses be configured? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Aug 2 14:59:43 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 2 Aug 2016 07:59:43 -0700 Subject: JDK 9 RFR of 8146215: (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently on Solaris-sparc with Unexpected type: text/plain In-Reply-To: References: <607BC614-DFBE-49B2-AA6D-5A01EFF21D56@oracle.com> <1C814958-7FA4-4F7A-BA69-E698EBE7AAD2@oracle.com> <07BA34F1-F454-4D2C-91CE-7698A65B0902@oracle.com> <96fab9bc-0afc-59a2-6da1-0a238bcd815a@oracle.com> Message-ID: <22E4D09F-EC6F-40B7-9FC5-6A06245209C9@oracle.com> On Aug 2, 2016, at 7:36 AM, Alan Bateman wrote: > On 01/08/2016 15:11, Brian Burkhalter wrote: >> >> Modified accordingly: http://cr.openjdk.java.net/~bpb/8146215/webrev.02/ > There is a still a volatile write to initialize fileNameMap to null at L38, this can be removed. Will do. >> >>> Alternatively just call URLConnection.getFileNameMap() each time. >> >> URLConnection.getFileNameMap() is synchronized and returns a new anonymous class instance at each invocation so this does not look to be a good idea. > I meant that we clean-up URLConnection.getFileNameMap(). I can look into that. >> >>> As regards ordering what what you have it okay. I assume it will be rare to set the property content.types.user.table and so the JDK's content-types.properties will be a fallback. >> >> Question is whether this should be a fallback on OS X and Windows as well. >> > On Windows then it's configured via the UI (backed by the registry) so probably not needed. Based on a test run the registry detector does not recognize for example the basic extensions mp3, mp4, nor pdf. > On OSX then then can the mappings that the UTI based detector uses be configured? Yes [1]. Brian [1] https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_declare/understand_utis_declare.html#//apple_ref/doc/uid/TP40001319-CH204-SW1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Aug 2 15:40:14 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 2 Aug 2016 08:40:14 -0700 Subject: JDK 9 RFR of 8146215: (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently on Solaris-sparc with Unexpected type: text/plain In-Reply-To: <18877efa-abb0-ab59-cce9-ea268a6b5a87@Oracle.com> References: <607BC614-DFBE-49B2-AA6D-5A01EFF21D56@oracle.com> <1C814958-7FA4-4F7A-BA69-E698EBE7AAD2@oracle.com> <07BA34F1-F454-4D2C-91CE-7698A65B0902@oracle.com> <96fab9bc-0afc-59a2-6da1-0a238bcd815a@oracle.com> <18877efa-abb0-ab59-cce9-ea268a6b5a87@Oracle.com> Message-ID: <1FB6FD1F-B953-4230-B25F-0A581B1DC415@oracle.com> Hi Roger, On Aug 2, 2016, at 7:21 AM, Roger Riggs wrote: > +1 > > Basic.java: Line 69: (pre-existing) Its probably useful to include the message from the exception, > it may provide some clue as to what the problem was. OK will update. >>> As regards ordering what what you have it okay. I assume it will be rare to set the property content.types.user.table and so the JDK's content-types.properties will be a fallback. >> >> Question is whether this should be a fallback on OS X and Windows as well. > +1 that would provide a consistent cross-platform fallback based on the system property "content.types.user.table". I concur and the change could be fairly straightforward. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Aug 3 00:59:39 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 2 Aug 2016 17:59:39 -0700 Subject: JDK 9 RFR of 8146215: (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently on Solaris-sparc with Unexpected type: text/plain In-Reply-To: <1FB6FD1F-B953-4230-B25F-0A581B1DC415@oracle.com> References: <607BC614-DFBE-49B2-AA6D-5A01EFF21D56@oracle.com> <1C814958-7FA4-4F7A-BA69-E698EBE7AAD2@oracle.com> <07BA34F1-F454-4D2C-91CE-7698A65B0902@oracle.com> <96fab9bc-0afc-59a2-6da1-0a238bcd815a@oracle.com> <18877efa-abb0-ab59-cce9-ea268a6b5a87@Oracle.com> <1FB6FD1F-B953-4230-B25F-0A581B1DC415@oracle.com> Message-ID: I?ve incorporated the previous comments: http://cr.openjdk.java.net/~bpb/8146215/webrev.03/ With respect to the previous version of the patch the class FileNameMapFileTypeDetector class has been removed and the references to it removed from the Linux and Solaris FileTypeDetectors. The functionality of FileNameMapFileTypeDetector is now moved to be a fallback for all platforms directly in AbstractFileTypeDetector.probeContentType() in the event that all detected FileTypeDetectors return null for the content type. URLConnection.getFileNameMap() is modified to create and retain a single static reference to an instance of an anonymous FileNameMap class instead of creating a new instance on each invocation. The method is also no longer synchronized instead relying on an internal lock in a hopefully correct manner. Thanks, Brian From brian.burkhalter at oracle.com Wed Aug 3 21:32:23 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Aug 2016 14:32:23 -0700 Subject: JDK 9 RFR of 8162745: content-types.properties files are missing some modern types Message-ID: <121DFF96-16E6-49FB-A74E-495813F5671E@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8162745 Patch: http://cr.openjdk.java.net/~bpb/8162745/webrev.00/ Add some content types from HTML5 and Xiph. Note that this patch depends on the prior application of the patch for JDK-8146215 [1] which is awaiting further review [2]. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8146215 [2] http://mail.openjdk.java.net/pipermail/nio-dev/2016-August/003804.html From brian.burkhalter at oracle.com Wed Aug 3 21:43:12 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Aug 2016 14:43:12 -0700 Subject: JDK 9 RFR of 8162902: Add some debugging output to test/java/nio/file/WatchService/DeleteInterference In-Reply-To: <1E5B9BDE-43F4-4CFB-A4D5-8E5707CD0194@oracle.com> References: <1E5B9BDE-43F4-4CFB-A4D5-8E5707CD0194@oracle.com> Message-ID: Ping! On Aug 1, 2016, at 6:40 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8162902 > Patch: http://cr.openjdk.java.net/~bpb/8162902/webrev.00/ > > Add a few printfs to see whether this can help bracket the problem described in the parent task. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Aug 3 23:42:00 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Aug 2016 16:42:00 -0700 Subject: JDK 9 RFR of 8163136: Add print statements to java/nio/file/WatchService/LotsOfCancels.java Message-ID: <6CF8E792-4929-4CCC-99BA-071363571242@oracle.com> Please review this test-only patch at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8163136 Patch: http://cr.openjdk.java.net/~bpb/8163136/webrev.00/ Add some print statements to see the state of the test if it times out. Thanks, Brian From Alan.Bateman at oracle.com Thu Aug 4 04:03:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Aug 2016 21:03:39 -0700 Subject: JDK 9 RFR of 8163136: Add print statements to java/nio/file/WatchService/LotsOfCancels.java In-Reply-To: <6CF8E792-4929-4CCC-99BA-071363571242@oracle.com> References: <6CF8E792-4929-4CCC-99BA-071363571242@oracle.com> Message-ID: <1c2cff2b-941b-7e94-12ce-bd307334c580@oracle.com> On 03/08/2016 16:42, Brian Burkhalter wrote: > Please review this test-only patch at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8163136 > Patch: http://cr.openjdk.java.net/~bpb/8163136/webrev.00/ > > Add some print statements to see the state of the test if it times out. > jtreg generates a thread dump when a test times out so you probably don't need most of these messages. However, printing the iteration is probably useful to see how many iterations have been done. It's very possible of course that the timeout isn't anything to do with this test, it could be something else on the system. -Alan From Alan.Bateman at oracle.com Thu Aug 4 04:05:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Aug 2016 21:05:54 -0700 Subject: JDK 9 RFR of 8162902: Add some debugging output to test/java/nio/file/WatchService/DeleteInterference In-Reply-To: References: <1E5B9BDE-43F4-4CFB-A4D5-8E5707CD0194@oracle.com> Message-ID: <14c4d148-611c-aec1-c905-80d6ed8cca2c@oracle.com> This test does 1024 iterations so I'm curious if jtreg will truncate the output. If it does then these traces might not be useful. -Alan On 03/08/2016 14:43, Brian Burkhalter wrote: > Ping! > > On Aug 1, 2016, at 6:40 PM, Brian Burkhalter > > wrote: > >> Please review at your convenience. >> >> Issue:https://bugs.openjdk.java.net/browse/JDK-8162902 >> Patch:http://cr.openjdk.java.net/~bpb/8162902/webrev.00/ >> >> >> Add a few printfs to see whether this can help bracket the problem >> described in the parent task. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Aug 4 04:21:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Aug 2016 21:21:30 -0700 Subject: JDK 9 RFR of 8146215: (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently on Solaris-sparc with Unexpected type: text/plain In-Reply-To: References: <607BC614-DFBE-49B2-AA6D-5A01EFF21D56@oracle.com> <1C814958-7FA4-4F7A-BA69-E698EBE7AAD2@oracle.com> <07BA34F1-F454-4D2C-91CE-7698A65B0902@oracle.com> <96fab9bc-0afc-59a2-6da1-0a238bcd815a@oracle.com> <18877efa-abb0-ab59-cce9-ea268a6b5a87@Oracle.com> <1FB6FD1F-B953-4230-B25F-0A581B1DC415@oracle.com> Message-ID: <8bf2cf8a-5201-f30c-cd1e-59aa3ff44ff6@oracle.com> On 02/08/2016 17:59, Brian Burkhalter wrote: > I?ve incorporated the previous comments: > > http://cr.openjdk.java.net/~bpb/8146215/webrev.03/ > > With respect to the previous version of the patch the class FileNameMapFileTypeDetector class has been removed and the references to it removed from the Linux and Solaris FileTypeDetectors. The functionality of FileNameMapFileTypeDetector is now moved to be a fallback for all platforms directly in AbstractFileTypeDetector.probeContentType() in the event that all detected FileTypeDetectors return null for the content type. > > URLConnection.getFileNameMap() is modified to create and retain a single static reference to an instance of an anonymous FileNameMap class instead of creating a new instance on each invocation. The method is also no longer synchronized instead relying on an internal lock in a hopefully correct manner. > Does getFileNameMap() need the synchronization? I assume not, in which case fileNameMapLock could be removed and it could be reduced down to: FileNameMap map = fileNameMap; if (map == null) { fileNameMap = map = new FileNameMap() { ... } } return map; The rest looks okay to me. -Alan From Roger.Riggs at Oracle.com Thu Aug 4 14:12:49 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 4 Aug 2016 10:12:49 -0400 Subject: JDK 9 RFR of 8162745: content-types.properties files are missing some modern types In-Reply-To: <121DFF96-16E6-49FB-A74E-495813F5671E@oracle.com> References: <121DFF96-16E6-49FB-A74E-495813F5671E@oracle.com> Message-ID: Hi Brian, Looks fine. BTW, is there an authority on these types and mappings. IANA or IETF? Roger On 8/3/2016 5:32 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8162745 > Patch: http://cr.openjdk.java.net/~bpb/8162745/webrev.00/ > > Add some content types from HTML5 and Xiph. Note that this patch depends on the prior application of the patch for JDK-8146215 [1] which is awaiting further review [2]. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8146215 > [2] http://mail.openjdk.java.net/pipermail/nio-dev/2016-August/003804.html From brian.burkhalter at oracle.com Thu Aug 4 15:43:46 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 4 Aug 2016 08:43:46 -0700 Subject: JDK 9 RFR of 8162745: content-types.properties files are missing some modern types In-Reply-To: References: <121DFF96-16E6-49FB-A74E-495813F5671E@oracle.com> Message-ID: Hi Roger, Yes, there are numerous sources of corroboration for these: [1] http://www.iana.org/assignments/media-types/ [2] https://tools.ietf.org/html/rfc4337 [2] https://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions [3] https://en.wikipedia.org/wiki/List_of_filename_extensions [4] https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats [5] https://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support [6] http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types Thanks, Brian On Aug 4, 2016, at 7:12 AM, Roger Riggs wrote: > Looks fine. > > BTW, is there an authority on these types and mappings. IANA or IETF? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Aug 4 15:48:45 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 4 Aug 2016 08:48:45 -0700 Subject: JDK 9 RFR of 8163136: Add print statements to java/nio/file/WatchService/LotsOfCancels.java In-Reply-To: <1c2cff2b-941b-7e94-12ce-bd307334c580@oracle.com> References: <6CF8E792-4929-4CCC-99BA-071363571242@oracle.com> <1c2cff2b-941b-7e94-12ce-bd307334c580@oracle.com> Message-ID: On Aug 3, 2016, at 9:03 PM, Alan Bateman wrote: > On 03/08/2016 16:42, Brian Burkhalter wrote: > >> Please review this test-only patch at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8163136 >> Patch: http://cr.openjdk.java.net/~bpb/8163136/webrev.00/ >> >> Add some print statements to see the state of the test if it times out. >> > jtreg generates a thread dump when a test times out so you probably don't need most of these messages. However, printing the iteration is probably useful to see how many iterations have been done. It's very possible of course that the timeout isn't anything to do with this test, it could be something else on the system. So do you think that this is sufficient as is? Given that the parent task was reported for Solaris SPARC only, another thought I had was to add a special case for that platform in the test with a very large timeout value to try to measure how long it takes the pool to terminate, that is to say if it actually does. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Thu Aug 4 16:06:34 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 4 Aug 2016 12:06:34 -0400 Subject: JDK 9 RFR of 8162745: content-types.properties files are missing some modern types In-Reply-To: References: <121DFF96-16E6-49FB-A74E-495813F5671E@oracle.com> Message-ID: <63d852d5-6433-dc1f-a631-0c320577e982@Oracle.com> Thanks, Roger On 8/4/2016 11:43 AM, Brian Burkhalter wrote: > Hi Roger, > > Yes, there are numerous sources of corroboration for these: > > [1] http://www.iana.org/assignments/media-types/ > [2] https://tools.ietf.org/html/rfc4337 > [2] https://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions > [3] https://en.wikipedia.org/wiki/List_of_filename_extensions > [4] > https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats > [5] https://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support > [6] http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types > > Thanks, > > Brian > > On Aug 4, 2016, at 7:12 AM, Roger Riggs > wrote: > >> Looks fine. >> >> BTW, is there an authority on these types and mappings. IANA or IETF? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Aug 4 16:10:26 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 4 Aug 2016 09:10:26 -0700 Subject: JDK 9 RFR of 8162902: Add some debugging output to test/java/nio/file/WatchService/DeleteInterference In-Reply-To: <14c4d148-611c-aec1-c905-80d6ed8cca2c@oracle.com> References: <1E5B9BDE-43F4-4CFB-A4D5-8E5707CD0194@oracle.com> <14c4d148-611c-aec1-c905-80d6ed8cca2c@oracle.com> Message-ID: <1145E502-4D9F-4B1E-840A-4B16C7E4CC5A@oracle.com> I verified before posting this RFR that the output is not truncated. An earlier version of this did have truncated output but I paired it down. Brian On Aug 3, 2016, at 9:05 PM, Alan Bateman wrote: > This test does 1024 iterations so I'm curious if jtreg will truncate the output. If it does then these traces might not be useful. > -Alan > > On 03/08/2016 14:43, Brian Burkhalter wrote: >> Ping! >> >> On Aug 1, 2016, at 6:40 PM, Brian Burkhalter wrote: >> >>> Please review at your convenience. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8162902 >>> Patch: http://cr.openjdk.java.net/~bpb/8162902/webrev.00/ >>> >>> Add a few printfs to see whether this can help bracket the problem described in the parent task. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Aug 4 17:13:19 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 4 Aug 2016 10:13:19 -0700 Subject: JDK 9 RFR of 8146215: (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently on Solaris-sparc with Unexpected type: text/plain In-Reply-To: <8bf2cf8a-5201-f30c-cd1e-59aa3ff44ff6@oracle.com> References: <607BC614-DFBE-49B2-AA6D-5A01EFF21D56@oracle.com> <1C814958-7FA4-4F7A-BA69-E698EBE7AAD2@oracle.com> <07BA34F1-F454-4D2C-91CE-7698A65B0902@oracle.com> <96fab9bc-0afc-59a2-6da1-0a238bcd815a@oracle.com> <18877efa-abb0-ab59-cce9-ea268a6b5a87@Oracle.com> <1FB6FD1F-B953-4230-B25F-0A581B1DC415@oracle.com> <8bf2cf8a-5201-f30c-cd1e-59aa3ff44ff6@oracle.com> Message-ID: <88436376-0B6F-4B36-A5C7-51B3249E2BE1@oracle.com> On Aug 3, 2016, at 9:21 PM, Alan Bateman wrote: > Does getFileNameMap() need the synchronization? I assume not, in which case fileNameMapLock could be removed and it could be reduced down to: > > FileNameMap map = fileNameMap; > if (map == null) { > fileNameMap = map = new FileNameMap() { ... } > } > return map; > > The rest looks okay to me. I updated URLConnection accordingly http://cr.openjdk.java.net/~bpb/8146215/webrev.04/ and reran the test job successfully. I assume that this should be good to go now. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Aug 4 17:42:30 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 4 Aug 2016 10:42:30 -0700 Subject: JDK 9 RFR of 8162745: content-types.properties files are missing some modern types In-Reply-To: <121DFF96-16E6-49FB-A74E-495813F5671E@oracle.com> References: <121DFF96-16E6-49FB-A74E-495813F5671E@oracle.com> Message-ID: > On 3 Aug 2016, at 14:32, Brian Burkhalter wrote: > > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8162745 > Patch: http://cr.openjdk.java.net/~bpb/8162745/webrev.00/ Looks fine. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Aug 4 20:54:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 Aug 2016 13:54:03 -0700 Subject: JDK 9 RFR of 8162902: Add some debugging output to test/java/nio/file/WatchService/DeleteInterference In-Reply-To: <1145E502-4D9F-4B1E-840A-4B16C7E4CC5A@oracle.com> References: <1E5B9BDE-43F4-4CFB-A4D5-8E5707CD0194@oracle.com> <14c4d148-611c-aec1-c905-80d6ed8cca2c@oracle.com> <1145E502-4D9F-4B1E-840A-4B16C7E4CC5A@oracle.com> Message-ID: <87264e31-6819-8ec8-0b51-cf497df9c0aa@oracle.com> On 04/08/2016 09:10, Brian Burkhalter wrote: > I verified before posting this RFR that the output is not truncated. > An earlier version of this did have truncated output but I paired it down. Good, in that case the changes looks okay to me. -Alan From brian.burkhalter at oracle.com Fri Aug 5 21:59:19 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Aug 2016 14:59:19 -0700 Subject: JDK 9 RFR of 8163305: Add some print instrumentation to java/nio/channels/Selector/RacyDeregister Message-ID: <0DEAC6FC-F0AD-409A-B0D1-04EA9CAFE3C9@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8163305 Patch: http://cr.openjdk.java.net/~bpb/8163305/webrev.00/ After entering the failure path, poll each second up to 60 seconds to see whether notification actually occurs but at a time later than expected. Thanks, Brian From brian.burkhalter at oracle.com Mon Aug 8 19:12:26 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 Aug 2016 12:12:26 -0700 Subject: JDK 9 RFR of 8163305: Add some print instrumentation to java/nio/channels/Selector/RacyDeregister In-Reply-To: <0DEAC6FC-F0AD-409A-B0D1-04EA9CAFE3C9@oracle.com> References: <0DEAC6FC-F0AD-409A-B0D1-04EA9CAFE3C9@oracle.com> Message-ID: <551497EF-5A94-4DEE-AB32-256516CA7547@oracle.com> I have modified the patch to perform more loop iterations on Windows http://cr.openjdk.java.net/~bpb/8163305/webrev.01/ as that is the only platform on which the failure has been observed, and then only once. Thanks, Brian On Aug 5, 2016, at 2:59 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8163305 > Patch: http://cr.openjdk.java.net/~bpb/8163305/webrev.00/ > > After entering the failure path, poll each second up to 60 seconds to see whether notification actually occurs but at a time later than expected. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Mon Aug 8 19:46:33 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 8 Aug 2016 15:46:33 -0400 Subject: JDK 9 RFR of 8146215: (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently on Solaris-sparc with Unexpected type: text/plain In-Reply-To: <88436376-0B6F-4B36-A5C7-51B3249E2BE1@oracle.com> References: <607BC614-DFBE-49B2-AA6D-5A01EFF21D56@oracle.com> <1C814958-7FA4-4F7A-BA69-E698EBE7AAD2@oracle.com> <07BA34F1-F454-4D2C-91CE-7698A65B0902@oracle.com> <96fab9bc-0afc-59a2-6da1-0a238bcd815a@oracle.com> <18877efa-abb0-ab59-cce9-ea268a6b5a87@Oracle.com> <1FB6FD1F-B953-4230-B25F-0A581B1DC415@oracle.com> <8bf2cf8a-5201-f30c-cd1e-59aa3ff44ff6@oracle.com> <88436376-0B6F-4B36-A5C7-51B3249E2BE1@oracle.com> Message-ID: Hi Brian, Looks fine. I'm not sure there are any changes except an import in SolarisFileSystemProvider.java; you might not need to update that. Good to go, Roger On 8/4/2016 1:13 PM, Brian Burkhalter wrote: > > On Aug 3, 2016, at 9:21 PM, Alan Bateman > wrote: > >> Does getFileNameMap() need the synchronization? I assume not, in >> which case fileNameMapLock could be removed and it could be reduced >> down to: >> >> FileNameMap map = fileNameMap; >> if (map == null) { >> fileNameMap = map = new FileNameMap() { ... } >> } >> return map; >> >> The rest looks okay to me. > > I updated URLConnection accordingly > > http://cr.openjdk.java.net/~bpb/8146215/webrev.04/ > > > and reran the test job successfully. I assume that this should be good > to go now. > > Thanks, > > Brian From brian.burkhalter at oracle.com Tue Aug 9 01:09:51 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 Aug 2016 18:09:51 -0700 Subject: JDK 9 RFR of 8163431: probeContentType/Basic.java fails after changes for JDK-8146215 Message-ID: <6A1411AE-F7E7-4851-9649-EE67097370FD@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8163431 Patch: http://cr.openjdk.java.net/~bpb/8163431/webrev.00/ Modify the test to allow for multiple possible MIME types for certain extensions for which there is ambiguity. Testing is in progress. Thanks, Brian From chris.hegarty at oracle.com Tue Aug 9 09:29:48 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 9 Aug 2016 10:29:48 +0100 Subject: JDK 9 RFR of 8163431: probeContentType/Basic.java fails after changes for JDK-8146215 In-Reply-To: <6A1411AE-F7E7-4851-9649-EE67097370FD@oracle.com> References: <6A1411AE-F7E7-4851-9649-EE67097370FD@oracle.com> Message-ID: <540DC61C-A822-42D4-B133-B4D506A6FADD@oracle.com> > On 9 Aug 2016, at 02:09, Brian Burkhalter wrote: > > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8163431 > Patch: http://cr.openjdk.java.net/~bpb/8163431/webrev.00/ This looks fine Brian. -Chris. > Modify the test to allow for multiple possible MIME types for certain extensions for which there is ambiguity. Testing is in progress. > > Thanks, > > Brian From chris.hegarty at oracle.com Tue Aug 9 13:33:28 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 9 Aug 2016 14:33:28 +0100 Subject: JDK 9 RFR of 8163305: Add some print instrumentation to java/nio/channels/Selector/RacyDeregister In-Reply-To: <551497EF-5A94-4DEE-AB32-256516CA7547@oracle.com> References: <0DEAC6FC-F0AD-409A-B0D1-04EA9CAFE3C9@oracle.com> <551497EF-5A94-4DEE-AB32-256516CA7547@oracle.com> Message-ID: > On 8 Aug 2016, at 20:12, Brian Burkhalter wrote: > > I have modified the patch to perform more loop iterations on Windows > > http://cr.openjdk.java.net/~bpb/8163305/webrev.01/ Looks ok Brian. -Chris. > as that is the only platform on which the failure has been observed, and then only once. > > Thanks, > > Brian > > On Aug 5, 2016, at 2:59 PM, Brian Burkhalter wrote: > >> Please review at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8163305 >> Patch: http://cr.openjdk.java.net/~bpb/8163305/webrev.00/ >> >> After entering the failure path, poll each second up to 60 seconds to see whether notification actually occurs but at a time later than expected. > From brian.burkhalter at oracle.com Thu Aug 11 18:46:26 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 11 Aug 2016 11:46:26 -0700 Subject: JDK 9 RFR of 8163136: Add print statements to java/nio/file/WatchService/LotsOfCancels.java In-Reply-To: References: <6CF8E792-4929-4CCC-99BA-071363571242@oracle.com> <1c2cff2b-941b-7e94-12ce-bd307334c580@oracle.com> Message-ID: PING! On Aug 4, 2016, at 8:48 AM, Brian Burkhalter wrote: > > On Aug 3, 2016, at 9:03 PM, Alan Bateman wrote: > >> On 03/08/2016 16:42, Brian Burkhalter wrote: >> >>> Please review this test-only patch at your convenience. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8163136 >>> Patch: http://cr.openjdk.java.net/~bpb/8163136/webrev.00/ >>> >>> Add some print statements to see the state of the test if it times out. >>> >> jtreg generates a thread dump when a test times out so you probably don't need most of these messages. However, printing the iteration is probably useful to see how many iterations have been done. It's very possible of course that the timeout isn't anything to do with this test, it could be something else on the system. > > So do you think that this is sufficient as is? Given that the parent task was reported for Solaris SPARC only, another thought I had was to add a special case for that platform in the test with a very large timeout value to try to measure how long it takes the pool to terminate, that is to say if it actually does. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre.iline at oracle.com Tue Aug 16 17:17:27 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 16 Aug 2016 10:17:27 -0700 Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests Message-ID: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com> Hi. Please review fixes related to module dependencies in a few jdk tests: http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/index.html The review contains a few cases where jdk.zipfs is added to the module list. This is happening because all TestNG tests which use compiler API require jdk.zipfs to be able to read the testng jar. This is unfortunate but there is no easy way around that. Shura From brian.burkhalter at oracle.com Tue Aug 16 17:42:35 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Aug 2016 10:42:35 -0700 Subject: JDK 9 RFR of 8163136: Add print statements to java/nio/file/WatchService/LotsOfCancels.java In-Reply-To: References: <6CF8E792-4929-4CCC-99BA-071363571242@oracle.com> <1c2cff2b-941b-7e94-12ce-bd307334c580@oracle.com> Message-ID: http://eng-sun.com/ping/ On Aug 11, 2016, at 11:46 AM, Brian Burkhalter wrote: > PING! > > On Aug 4, 2016, at 8:48 AM, Brian Burkhalter wrote: > >> >> On Aug 3, 2016, at 9:03 PM, Alan Bateman wrote: >> >>> On 03/08/2016 16:42, Brian Burkhalter wrote: >>> >>>> Please review this test-only patch at your convenience. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8163136 >>>> Patch: http://cr.openjdk.java.net/~bpb/8163136/webrev.00/ >>>> >>>> Add some print statements to see the state of the test if it times out. >>>> >>> jtreg generates a thread dump when a test times out so you probably don't need most of these messages. However, printing the iteration is probably useful to see how many iterations have been done. It's very possible of course that the timeout isn't anything to do with this test, it could be something else on the system. >> >> So do you think that this is sufficient as is? Given that the parent task was reported for Solaris SPARC only, another thought I had was to add a special case for that platform in the test with a very large timeout value to try to measure how long it takes the pool to terminate, that is to say if it actually does. >> >> Thanks, >> >> Brian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Aug 17 00:30:53 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 17 Aug 2016 08:30:53 +0800 Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests In-Reply-To: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com> References: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com> Message-ID: <3b1f5d47-e64f-1f46-1486-889fa823841c@oracle.com> Hi Shura I am looking at test/jdk/security/jarsigner/Spec.java. IMHO, even on a Solaris, without the SunPKCS11 provider at runtime, this test should be able to find Signature and MessageDigest implementations from the SunRsaSign and SUN provider. Is the new @modules dependency necessary? In fact, I am curious how you note this test. Does it fail with some special settings? Thanks Max On 8/17/2016 1:17, Alexandre (Shura) Iline wrote: > Hi. > > Please review fixes related to module dependencies in a few jdk tests: > http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/index.html > > The review contains a few cases where jdk.zipfs is added to the module list. This is happening because all TestNG tests which use compiler API require jdk.zipfs to be able to read the testng jar. This is unfortunate but there is no easy way around that. > > Shura > > > From alexandre.iline at oracle.com Wed Aug 17 01:26:26 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 16 Aug 2016 18:26:26 -0700 Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests In-Reply-To: <3b1f5d47-e64f-1f46-1486-889fa823841c@oracle.com> References: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com> <3b1f5d47-e64f-1f46-1486-889fa823841c@oracle.com> Message-ID: Hi, Max. Excerpt from JTReg documentation: ========================================================================================================= @modules [/]+ Express a dependence on a modules in the system being tested, and optionally, on selected internal packages in some or all of those modules. If no dependencies are specified explicitly, a default set of dependencies will be read from the modules entry in test suite configuration files. A test will not be run if the system being tested does not contain all of the specified modules. Note: Specifying an entry that includes a dependence on an internal package is essentially equivalent to using -XaddExports:/ALL-UNNAMED when the test is compiled and run. ========================================================================================================= Before the suggested fix, the test in question would fail on a system with no jdk.crypto.pkcs11. That could be emulated by: $ jtreg ... -javaoptions:"-limitmods jdk.jartool" jdk/security/jarsigner/Spec.java ... FAILED: jdk/security/jarsigner/Spec.java ... $ jtreg ... -javaoptions:"-limitmods jdk.jartool,jdk.crypto.pkcs11" jdk/security/jarsigner/Spec.java ... Passed: jdk/security/jarsigner/Spec.java ... $ With my fix, the test will not be selected for execution when there is no jdk.crypto.pkcs11: $ jtreg ... -javaoptions:"-limitmods jdk.jartool" jdk/security/jarsigner/Spec.java ... Test results: no tests selected ? $ Shura > On Aug 16, 2016, at 5:30 PM, Weijun Wang wrote: > > Hi Shura > > I am looking at test/jdk/security/jarsigner/Spec.java. > > IMHO, even on a Solaris, without the SunPKCS11 provider at runtime, this test should be able to find Signature and MessageDigest implementations from the SunRsaSign and SUN provider. > > Is the new @modules dependency necessary? In fact, I am curious how you note this test. Does it fail with some special settings? > > Thanks > Max > > On 8/17/2016 1:17, Alexandre (Shura) Iline wrote: >> Hi. >> >> Please review fixes related to module dependencies in a few jdk tests: >> http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/index.html >> >> The review contains a few cases where jdk.zipfs is added to the module list. This is happening because all TestNG tests which use compiler API require jdk.zipfs to be able to read the testng jar. This is unfortunate but there is no easy way around that. >> >> Shura >> >> >> From weijun.wang at oracle.com Wed Aug 17 01:48:52 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 17 Aug 2016 09:48:52 +0800 Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests In-Reply-To: References: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com> <3b1f5d47-e64f-1f46-1486-889fa823841c@oracle.com> Message-ID: <8D77C9ED-BA5E-4F94-BE2D-C73E418C666F@oracle.com> > On Aug 17, 2016, at 9:26 AM, Alexandre (Shura) Iline wrote: > > Before the suggested fix, the test in question would fail on a system with no jdk.crypto.pkcs11. That could be emulated by: > $ jtreg ... -javaoptions:"-limitmods jdk.jartool" jdk/security/jarsigner/Spec.java > ... > FAILED: jdk/security/jarsigner/Spec.java > ... > $ jtreg ... -javaoptions:"-limitmods jdk.jartool,jdk.crypto.pkcs11" jdk/security/jarsigner/Spec.java > ... > Passed: jdk/security/jarsigner/Spec.java > ... > $ Thanks very much for the detailed answer. Just a small suggestion: Can you try using jdk.crypto.ec module instead? It also provides all EC-related algorithms and it is available and loaded out-of-box on all platforms? --Max From Alan.Bateman at oracle.com Wed Aug 17 06:11:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Aug 2016 07:11:22 +0100 Subject: JDK 9 RFR of 8163305: Add some print instrumentation to java/nio/channels/Selector/RacyDeregister In-Reply-To: <551497EF-5A94-4DEE-AB32-256516CA7547@oracle.com> References: <0DEAC6FC-F0AD-409A-B0D1-04EA9CAFE3C9@oracle.com> <551497EF-5A94-4DEE-AB32-256516CA7547@oracle.com> Message-ID: <5e90229d-64b2-0a37-2990-7981448d086d@oracle.com> On 08/08/2016 20:12, Brian Burkhalter wrote: > I have modified the patch to perform more loop iterations on Windows > > http://cr.openjdk.java.net/~bpb/8163305/webrev.01/ > > > as that is the only platform on which the failure has been observed, > and then only once. > The formatting looks really messy at L105-109. Have you considered refactoring the test to make it more readable? -Alan From frank.yuan at oracle.com Wed Aug 17 10:21:13 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 17 Aug 2016 18:21:13 +0800 Subject: JDK-8054039 Deadlock during interrupting FileChannel In-Reply-To: <034801d0eba7$b1448d30$13cda790$@oracle.com> References: <00fe01d08bd0$6314f280$293ed780$@oracle.com> <5550803B.50203@oracle.com> <24497227-B196-4F23-A84E-F51839F83D88@oracle.com> <00e201d098ef$2a7dfd50$7f79f7f0$@oracle.com> <01f501d0c51b$9b6d3a00$d247ae00$@oracle.com> <55B09C61.6000005@oracle.com> <012c01d0ea1b$74666ab0$5d334010$@oracle.com> <9E67E71D-4861-4B5C-868C-BDE0878E3533@oracle.com> <023401d0ead5$73d818e0$5b884aa0$@oracle.com> <3C7C5557-378D-49A9-82FD-5032018C87C8@oracle.com> <034801d0eba7$b1448d30$13cda790$@oracle.com> Message-ID: <021a01d1f871$199541a0$4cbfc4e0$@oracle.com> Hi I reclaimed this task after a long time of suspending(really sorry for that.) However, I am sure for the fix now, that is the solution 1 which we talked about. I made an update for the latest code, would you like to check again: http://cr.openjdk.java.net/~fyuan/8054039/webrev.00/ ? As you known, this failure scenario is like: Thread 1 hold blockerLock of thread 2 and try to hold closeLock of FileChannel 1 Thread 2 hold closeLock of FileChannel 1 and try to hold blockerLock of thread 2, i.e. its own thread To solve the deadlock, this patch won't try to hold blockerLock of current thread in FileChannel, look at the change in NativeThreadSet.java if (interrupted) - Thread.currentThread().interrupt(); + SharedSecrets.getJavaLangAccess().doInterrupt(Thread.currentThread()); } Here, it only need to set the interrupted flag, doesn't need to call Interruptible.interrupt() extra, because either .interrupt() will call it(since current thread is already interrupted its interrupt method must be already invoked) or the AbstractInterruptibleChannel object will call it in the begin method(because we have set the interrupted flag again) if current thread has an Interruptible object. Btw, I am not sure if we need to add any note in the comment of AbstractInterruptibleChannel.implCloseChannel() to state the implementation must avoid to call interrupt method of current thread. Thanks Frank From: Frank Yuan [mailto:frank.yuan at oracle.com] Sent: Thursday, September 10, 2015 5:04 PM To: 'Brian Burkhalter'; 'nio-dev' Cc: 'FELIX YANG' Subject: RE: JDK-8054039 Deadlock during interrupting FileChannel Hi Frank, On Sep 9, 2015, at 12:59 AM, Frank Yuan > wrote: Thank you for review and your comments:) You are welcome. The size of my last mail is too large, is still held by maillist moderator, I have to send some content again(the diagram still can't be attached.). You could upload the diagram and a webrev to cr.openjdk.java.net assuming you have an ID. If not, I could do it for you. I have uploaded the diagram to the bug https://bugs.openjdk.java.net/browse/JDK-8054039, hope more people can review it. I am suspicious of the use of reflection here. I also have some concern for this solution, because in this fix nio will depend on the private method of Thread -- interrupt0, it will break the encapsulation. However it's an available solution in theory. True but I think the second one is better. Within the scope of AbstractInterruptibleChannel I do not see any problem with the change that you propose. Given that the affected instance variables are private to the class and that AtomicBoolean "generally" follows the rules for volatiles it looks conceptually valid. I do not know however about the implications with respect to interactions with other classes. For example, could this change provoke some unforeseen behavior as a result of subtle changes in timing? As my understood, this solution won't spend more time on begin() than the old code, compareAndSet is atomic and there is no loop or wait. Anyway I am not sure your concern, will do more tests, hope more people can review it. Indeed I don't know whether there would be any effect: it was simply an observation. I expect others will comment when they have time. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Aug 17 14:46:41 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Aug 2016 07:46:41 -0700 Subject: JDK 9 RFR of 8163305: Add some print instrumentation to java/nio/channels/Selector/RacyDeregister In-Reply-To: <5e90229d-64b2-0a37-2990-7981448d086d@oracle.com> References: <0DEAC6FC-F0AD-409A-B0D1-04EA9CAFE3C9@oracle.com> <551497EF-5A94-4DEE-AB32-256516CA7547@oracle.com> <5e90229d-64b2-0a37-2990-7981448d086d@oracle.com> Message-ID: <050120A3-3111-43A3-8632-9FCBFEB7501E@oracle.com> On Aug 16, 2016, at 11:11 PM, Alan Bateman wrote: > On 08/08/2016 20:12, Brian Burkhalter wrote: >> I have modified the patch to perform more loop iterations on Windows >> >> http://cr.openjdk.java.net/~bpb/8163305/webrev.01/ >> >> as that is the only platform on which the failure has been observed, and then only once. >> > The formatting looks really messy at L105-109. Have you considered refactoring the test to make it more readable? This was already approved and pushed last week. The formatting is ugly but it does stay within the 80 column limit, which if probably why it looks messy. If desired I can clean this up under a new issue. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre.iline at oracle.com Wed Aug 17 16:40:58 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 17 Aug 2016 09:40:58 -0700 Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests In-Reply-To: <8D77C9ED-BA5E-4F94-BE2D-C73E418C666F@oracle.com> References: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com> <3b1f5d47-e64f-1f46-1486-889fa823841c@oracle.com> <8D77C9ED-BA5E-4F94-BE2D-C73E418C666F@oracle.com> Message-ID: <4371BA82-A2A1-4AC5-8477-F46A589F52E3@oracle.com> Thank you! Fixed in place: http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/test/jdk/security/jarsigner/Spec.java.sdiff.html Shura > On Aug 16, 2016, at 6:48 PM, Wang Weijun wrote: > > >> On Aug 17, 2016, at 9:26 AM, Alexandre (Shura) Iline wrote: >> >> Before the suggested fix, the test in question would fail on a system with no jdk.crypto.pkcs11. That could be emulated by: >> $ jtreg ... -javaoptions:"-limitmods jdk.jartool" jdk/security/jarsigner/Spec.java >> ... >> FAILED: jdk/security/jarsigner/Spec.java >> ... >> $ jtreg ... -javaoptions:"-limitmods jdk.jartool,jdk.crypto.pkcs11" jdk/security/jarsigner/Spec.java >> ... >> Passed: jdk/security/jarsigner/Spec.java >> ... >> $ > > Thanks very much for the detailed answer. > > Just a small suggestion: Can you try using jdk.crypto.ec module instead? It also provides all EC-related algorithms and it is available and loaded out-of-box on all platforms? > > --Max > From artem.smotrakov at oracle.com Thu Aug 18 17:19:20 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 18 Aug 2016 10:19:20 -0700 Subject: [9] RFR: 8164159: java/nio/file/WatchService/UpdateInterference.java test leaves daemon threads In-Reply-To: References: Message-ID: <5c3ebbbd-25ec-0c4d-0a2d-59a9d09d76b5@oracle.com> Re-sending nio-dev at openjdk.java.net Artem On 08/16/2016 04:11 PM, Artem Smotrakov wrote: > Hello, > > Please review the following patch for > java/nio/file/WatchService/UpdateInterference.java test. > > The test creates a couple of daemon threads which have an infinite > loop inside. When the test finishes, those daemon still keep running > as long as jtreg use this instance of JVM to run other tests (the test > doesn't run in othervm mode). > > The test also creates a WatchService which creates a > "FileSystemWatchService" daemon thread. Then, the test doesn't close > this WatchService, and as a result, this daemon thread keeps running > as well. > > The test shouldn't leave daemon threads when it finishes. It may slow > down further test execution. If other tests also leave daemon threads, > it may cause intermittent test failures, see for example JDK-8160642 > and JDK-8162757. > > The patch updates the test with the following: > - threads are not daemons any more > - "while" loops are not infinite > - the test waits for threads to finish before closing a watch service > to avoid ClosedWatchServiceException > - the test closes a watch service in try-with-resources block > - the test removes temporary files and directories in the end > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164159 > Webrev: http://cr.openjdk.java.net/~asmotrak/8164159/webrev.00/ > > Artem From Alan.Bateman at oracle.com Thu Aug 18 19:42:49 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Aug 2016 20:42:49 +0100 Subject: [9] RFR: 8164159: java/nio/file/WatchService/UpdateInterference.java test leaves daemon threads In-Reply-To: <5c3ebbbd-25ec-0c4d-0a2d-59a9d09d76b5@oracle.com> References: <5c3ebbbd-25ec-0c4d-0a2d-59a9d09d76b5@oracle.com> Message-ID: <8c7b7387-a241-8539-dc4b-9be0602ae493@oracle.com> On 18/08/2016 18:19, Artem Smotrakov wrote: > >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164159 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8164159/webrev.00/ The comment in the finally block is confusing. It says that threads will stop before the WatchService is closed but it's the other way around - the WatchService::close method will be invoked before the finally block executes. This means that ClosedWatchServiceException will likely br thrown and the stack trace recorded in the test output. A minor suggestion, can Thread one and two be renamed to t1 and t2 to make it a bit more readable? Also no need to initialize to volatile stop to false as that is its initial value. -Alan. From artem.smotrakov at oracle.com Thu Aug 18 21:56:09 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 18 Aug 2016 14:56:09 -0700 Subject: [9] RFR: 8164159: java/nio/file/WatchService/UpdateInterference.java test leaves daemon threads In-Reply-To: <8c7b7387-a241-8539-dc4b-9be0602ae493@oracle.com> References: <5c3ebbbd-25ec-0c4d-0a2d-59a9d09d76b5@oracle.com> <8c7b7387-a241-8539-dc4b-9be0602ae493@oracle.com> Message-ID: <885f17ba-4fc0-0982-dfd6-c6f300979514@oracle.com> Thank you for review Alan. Please see inline. On 08/18/2016 12:42 PM, Alan Bateman wrote: > > > On 18/08/2016 18:19, Artem Smotrakov wrote: >> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164159 >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164159/webrev.00/ > > The comment in the finally block is confusing. It says that threads > will stop before the WatchService is closed but it's the other way > around - the WatchService::close method will be invoked before the > finally block executes. This means that ClosedWatchServiceException > will likely br thrown and the stack trace recorded in the test output. There are two try-finally blocks. First one creates a WatchService, and contains a nested try-finally block. The "stop" flag is set to true in this nested try-finally block, so that the test waits for threads to finish before the watch service is closed. I am not a fan of many nested "try" blocks, anonymous classes, etc, because they don't usually make code more readable. But on the other hand, I didn't want to re-write the test much. > > A minor suggestion, can Thread one and two be renamed to t1 and t2 to > make it a bit more readable? Sure. I am wondering if we could use some other names, for example, mickeyMouseThread and winnieThePoohThread. Anyway, t1 and t2 are also fine. > Also no need to initialize to volatile stop to false as that is its > initial value. Of course. Could you please take a look at updated webrev? http://cr.openjdk.java.net/~asmotrak/8164159/webrev.01/ Artem > > -Alan. From brian.burkhalter at oracle.com Fri Aug 19 18:28:17 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 19 Aug 2016 11:28:17 -0700 Subject: [TEST-ONLY] JDK 9 RFR of 8164432: java/nio/file/Files/probeContentType/Basic.java fails on windows for Content type: audio/vnd.dlna.adts Message-ID: Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8164432 Patch: [1] Add audio/vnd.dlna.adts as an allowed type for the file extension ?aac? for Advanced Audio Coding. Thanks, Brian [1] diff --- a/test/java/nio/file/Files/probeContentType/Basic.java +++ b/test/java/nio/file/Files/probeContentType/Basic.java @@ -174,27 +174,27 @@ // Verify that certain media extensions are mapped to the correct type. String[] extensions = new String[]{ "aac", "flac", "jpg", "mp3", "mp4", "pdf", "png", "webm" }; String[][] expectedTypes = new String[][] { - {"audio/aac", "audio/x-aac"}, + {"audio/aac", "audio/x-aac", "audio/vnd.dlna.adts"}, {"audio/flac", "audio/x-flac"}, {"image/jpeg"}, {"audio/mpeg"}, {"video/mp4"}, {"application/pdf"}, {"image/png"}, {"video/webm"} }; failures += checkContentTypes(extensions, expectedTypes); if (failures > 0) { throw new RuntimeException("Test failed!"); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Fri Aug 19 22:02:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 19 Aug 2016 15:02:48 -0700 Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests In-Reply-To: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com> References: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com> Message-ID: <9E7EBD37-4D3F-4B62-A34A-BC998D5F2A6D@oracle.com> > On Aug 16, 2016, at 10:17 AM, Alexandre (Shura) Iline wrote: > > Hi. > > Please review fixes related to module dependencies in a few jdk tests: > http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/index.html Looks okay. I will sponsor this patch for you. Mandy From Alan.Bateman at oracle.com Mon Aug 22 08:01:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Aug 2016 09:01:40 +0100 Subject: [TEST-ONLY] JDK 9 RFR of 8164432: java/nio/file/Files/probeContentType/Basic.java fails on windows for Content type: audio/vnd.dlna.adts In-Reply-To: References: Message-ID: <1fd5ece2-8897-745d-c0ce-8aab897fbb08@oracle.com> On 19/08/2016 19:28, Brian Burkhalter wrote: > Please review at your convenience: > > Issue:https://bugs.openjdk.java.net/browse/JDK-8164432 > Patch:[1] > > Add audio/vnd.dlna.adts as an allowed type for the file extension > ?aac? for Advanced Audio Coding. > > Thanks, > > Brian Looks okay but I have a general concern that the list of extensions now tested by this test makes it way too sensitive again to configuration. More specifically, I wonder if "acces", "flac", and "webm" could be dropped from the list. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Aug 22 13:56:12 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 22 Aug 2016 06:56:12 -0700 Subject: [TEST-ONLY] JDK 9 RFR of 8164432: java/nio/file/Files/probeContentType/Basic.java fails on windows for Content type: audio/vnd.dlna.adts In-Reply-To: <1fd5ece2-8897-745d-c0ce-8aab897fbb08@oracle.com> References: <1fd5ece2-8897-745d-c0ce-8aab897fbb08@oracle.com> Message-ID: I have no problem dropping AAC and FLAC but webm seems unambiguous. Brian On Aug 22, 2016, at 1:01 AM, Alan Bateman wrote: > Looks okay but I have a general concern that the list of extensions now tested by this test makes it way too sensitive again to configuration. More specifically, I wonder if "acces", "flac", and "webm" could be dropped from the list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Aug 22 14:02:03 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 22 Aug 2016 07:02:03 -0700 Subject: [TEST-ONLY] JDK 9 RFR of 8164432: java/nio/file/Files/probeContentType/Basic.java fails on windows for Content type: audio/vnd.dlna.adts In-Reply-To: References: <1fd5ece2-8897-745d-c0ce-8aab897fbb08@oracle.com> Message-ID: I filed https://bugs.openjdk.java.net/browse/JDK-8164556 to deal with this. Brian On Aug 22, 2016, at 6:56 AM, Brian Burkhalter wrote: > I have no problem dropping AAC and FLAC but webm seems unambiguous. > > Brian > > On Aug 22, 2016, at 1:01 AM, Alan Bateman wrote: > >> Looks okay but I have a general concern that the list of extensions now tested by this test makes it way too sensitive again to configuration. More specifically, I wonder if "acces", "flac", and "webm" could be dropped from the list. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Aug 22 15:14:02 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 22 Aug 2016 08:14:02 -0700 Subject: JDK 9 RFR of 8164556: Drop AAC and FLAC from content type check in java/nio/file/Files/probeContentType/Basic.java Message-ID: <1339C498-A18A-4AA9-9C1C-2D40A9E44974@oracle.com> Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8164556 Patch: http://cr.openjdk.java.net/~bpb/8164556/webrev.00/ The file extensions for the AAC and FLAC audio encodings appear to map to different and unpredictable MIME types depending on the system configuration and these MIME types differ from the respective ones in the fall back content types files. The best option seems to remove these extensions from the test as the remaining extensions give predictable results. Thanks, Brian From brian.burkhalter at oracle.com Mon Aug 22 17:47:29 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 22 Aug 2016 10:47:29 -0700 Subject: JDK 9 RFR of 8164556: Drop AAC and FLAC from content type check in java/nio/file/Files/probeContentType/Basic.java In-Reply-To: <1339C498-A18A-4AA9-9C1C-2D40A9E44974@oracle.com> References: <1339C498-A18A-4AA9-9C1C-2D40A9E44974@oracle.com> Message-ID: <63FC4854-274B-4BDB-8AC5-9AB42758A6A4@oracle.com> Regression test job passed on all platforms. On Aug 22, 2016, at 8:14 AM, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8164556 > Patch: http://cr.openjdk.java.net/~bpb/8164556/webrev.00/ > > The file extensions for the AAC and FLAC audio encodings appear to map to different and unpredictable MIME types depending on the system configuration and these MIME types differ from the respective ones in the fall back content types files. The best option seems to remove these extensions from the test as the remaining extensions give predictable results. > > Thanks, > > Brian From artem.smotrakov at oracle.com Tue Aug 23 00:28:14 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 22 Aug 2016 17:28:14 -0700 Subject: [9] RFR: 8164166: Make sure java/nio/channels tests shutdown asynchronous channel groups Message-ID: <194a8062-6187-3bc4-c7a2-06f7f45a348c@oracle.com> Hello, Please review the following patch for a couple of java/nio/channels tests. A couple of test failures have been observed, and jstack reported many daemon threads which were not related to failed tests (please see see JDK-8162757 and JDK-8162757 for details). The daemon threads were running EPollPort.EventHandlerTask class. I found a number of tests which run in agent VM, and start such daemon threads by opening an AsynchronousChannelGroup. If I understand correctly, those daemon threads are supposed to stop by calling AsynchronousChannelGroup.shutdown() method. I noticed that some tests don't guarantee that asynchronous channel groups are always shutdown. Please see more details in the bug. The patch below updates java/nio/channel tests for AsynchronousChannelGroup to always shutdown groups. As an enhancement, it updates the tests to use try-with-resources block in a couple of places. I am not familiar with EPollPort class, but at first glance, the logic looks quite complex. If EPollPort.EventHandlerTask daemon threads still appear after this patch, then there may be a bug in NIO (something may get out of sync while shutting down the daemon threads). Bug: https://bugs.openjdk.java.net/browse/JDK-8164166 Webrev: http://cr.openjdk.java.net/~asmotrak/8164166/webrev.00/ Artem From frank.yuan at oracle.com Tue Aug 23 03:25:40 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Tue, 23 Aug 2016 11:25:40 +0800 Subject: JDK-8054039 Deadlock during interrupting FileChannel In-Reply-To: <021f01d1f871$1f8a1130$5e9e3390$@oracle.com> References: <00fe01d08bd0$6314f280$293ed780$@oracle.com> <5550803B.50203@oracle.com> <24497227-B196-4F23-A84E-F51839F83D88@oracle.com> <00e201d098ef$2a7dfd50$7f79f7f0$@oracle.com> <01f501d0c51b$9b6d3a00$d247ae00$@oracle.com> <55B09C61.6000005@oracle.com> <012c01d0ea1b$74666ab0$5d334010$@oracle.com> <9E67E71D-4861-4B5C-868C-BDE0878E3533@oracle.com> <023401d0ead5$73d818e0$5b884aa0$@oracle.com> <3C7C5557-378D-49A9-82FD-5032018C87C8@oracle.com> <034801d0eba7$b1448d30$13cda790$@oracle.com> <021f01d1f871$1f8a1130$5e9e3390$@oracle.com> Message-ID: <029901d1fcee$0aaf6d60$200e4820$@oracle.com> Does anybody have any comments? Frank From: Frank Yuan [mailto:frank.yuan at oracle.com] Sent: Wednesday, August 17, 2016 6:21 PM To: 'Brian Burkhalter'; 'Daniel Fuchs'; 'nio-dev' Subject: RE: JDK-8054039 Deadlock during interrupting FileChannel Hi I reclaimed this task after a long time of suspending(really sorry for that.) However, I am sure for the fix now, that is the solution 1 which we talked about. I made an update for the latest code, would you like to check again: http://cr.openjdk.java.net/~fyuan/8054039/webrev.00/ ? As you known, this failure scenario is like: Thread 1 hold blockerLock of thread 2 and try to hold closeLock of FileChannel 1 Thread 2 hold closeLock of FileChannel 1 and try to hold blockerLock of thread 2, i.e. its own thread To solve the deadlock, this patch won't try to hold blockerLock of current thread in FileChannel, look at the change in NativeThreadSet.java if (interrupted) - Thread.currentThread().interrupt(); + SharedSecrets.getJavaLangAccess().doInterrupt(Thread.currentThread()); } Here, it only need to set the interrupted flag, doesn't need to call Interruptible.interrupt() extra, because either .interrupt() will call it(since current thread is already interrupted its interrupt method must be already invoked) or the AbstractInterruptibleChannel object will call it in the begin method(because we have set the interrupted flag again) if current thread has an Interruptible object. Btw, I am not sure if we need to add any note in the comment of AbstractInterruptibleChannel.implCloseChannel() to state the implementation must avoid to call interrupt method of current thread. Thanks Frank From: Frank Yuan [mailto:frank.yuan at oracle.com] Sent: Thursday, September 10, 2015 5:04 PM To: 'Brian Burkhalter'; 'nio-dev' Cc: 'FELIX YANG' Subject: RE: JDK-8054039 Deadlock during interrupting FileChannel Hi Frank, On Sep 9, 2015, at 12:59 AM, Frank Yuan > wrote: Thank you for review and your comments:) You are welcome. The size of my last mail is too large, is still held by maillist moderator, I have to send some content again(the diagram still can't be attached.). You could upload the diagram and a webrev to cr.openjdk.java.net assuming you have an ID. If not, I could do it for you. I have uploaded the diagram to the bug https://bugs.openjdk.java.net/browse/JDK-8054039, hope more people can review it. I am suspicious of the use of reflection here. I also have some concern for this solution, because in this fix nio will depend on the private method of Thread -- interrupt0, it will break the encapsulation. However it's an available solution in theory. True but I think the second one is better. Within the scope of AbstractInterruptibleChannel I do not see any problem with the change that you propose. Given that the affected instance variables are private to the class and that AtomicBoolean "generally" follows the rules for volatiles it looks conceptually valid. I do not know however about the implications with respect to interactions with other classes. For example, could this change provoke some unforeseen behavior as a result of subtle changes in timing? As my understood, this solution won't spend more time on begin() than the old code, compareAndSet is atomic and there is no loop or wait. Anyway I am not sure your concern, will do more tests, hope more people can review it. Indeed I don't know whether there would be any effect: it was simply an observation. I expect others will comment when they have time. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Aug 23 09:40:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 Aug 2016 10:40:27 +0100 Subject: JDK 9 RFR of 8164556: Drop AAC and FLAC from content type check in java/nio/file/Files/probeContentType/Basic.java In-Reply-To: <1339C498-A18A-4AA9-9C1C-2D40A9E44974@oracle.com> References: <1339C498-A18A-4AA9-9C1C-2D40A9E44974@oracle.com> Message-ID: On 22/08/2016 16:14, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8164556 > Patch: http://cr.openjdk.java.net/~bpb/8164556/webrev.00/ > > The file extensions for the AAC and FLAC audio encodings appear to map to different and unpredictable MIME types depending on the system configuration and these MIME types differ from the respective ones in the fall back content types files. The best option seems to remove these extensions from the test as the remaining extensions give predictable results. > Looks okay to me. I guess I would drop webm too but if you are confident it won't be problematic then no issue leaving it in. -Alan From Alan.Bateman at oracle.com Tue Aug 23 09:50:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 Aug 2016 10:50:53 +0100 Subject: [9] RFR: 8164166: Make sure java/nio/channels tests shutdown asynchronous channel groups In-Reply-To: <194a8062-6187-3bc4-c7a2-06f7f45a348c@oracle.com> References: <194a8062-6187-3bc4-c7a2-06f7f45a348c@oracle.com> Message-ID: <4cda047f-7b23-b3a1-885c-d3c0180d3d87@oracle.com> On 23/08/2016 01:28, Artem Smotrakov wrote: > : > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164166 > Webrev: http://cr.openjdk.java.net/~asmotrak/8164166/webrev.00/ For test/java/nio/channels/AsynchronousChannelGroup/Basic.java then it would be a lot cleaner to put the cleanup in shutdownTests, e.g.: AsynchronousChannelGroup group = ... try { testShutdownWithNoChannels(pool, group); } finally { group.shutdown(); } In GroupOfOne then L47-49 isn't early to read. If you move the bind into the try-finally, as in: listener.bind(new InetSocketAddress(0))) then it would be a bit easier. Same comment for the changes to Identify and testRestart in Restart.java. In testRestart then it looks like the try is in the wrong place, I assume you want: group = ... try { testRestart(...) } finally { group.shutdown(); } -Alan From Alan.Bateman at oracle.com Tue Aug 23 09:55:28 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 Aug 2016 10:55:28 +0100 Subject: [9] RFR: 8164159: java/nio/file/WatchService/UpdateInterference.java test leaves daemon threads In-Reply-To: <885f17ba-4fc0-0982-dfd6-c6f300979514@oracle.com> References: <5c3ebbbd-25ec-0c4d-0a2d-59a9d09d76b5@oracle.com> <8c7b7387-a241-8539-dc4b-9be0602ae493@oracle.com> <885f17ba-4fc0-0982-dfd6-c6f300979514@oracle.com> Message-ID: On 18/08/2016 22:56, Artem Smotrakov wrote: > : > > Could you please take a look at updated webrev? > > http://cr.openjdk.java.net/~asmotrak/8164159/webrev.01/ Updated webrev looks okay to me. -Alan From brian.burkhalter at oracle.com Tue Aug 23 15:14:40 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Aug 2016 08:14:40 -0700 Subject: JDK 9 RFR of 8164556: Drop AAC and FLAC from content type check in java/nio/file/Files/probeContentType/Basic.java In-Reply-To: References: <1339C498-A18A-4AA9-9C1C-2D40A9E44974@oracle.com> Message-ID: <5529959A-7FF1-41D4-B495-B6925525E9AF@oracle.com> On Aug 23, 2016, at 2:40 AM, Alan Bateman wrote: >> The file extensions for the AAC and FLAC audio encodings appear to map to different and unpredictable MIME types depending on the system configuration and these MIME types differ from the respective ones in the fall back content types files. The best option seems to remove these extensions from the test as the remaining extensions give predictable results. >> > Looks okay to me. I guess I would drop webm too but if you are confident it won't be problematic then no issue leaving it in. It?s possible it could be problematic but I have not seen an instance of where the MIME type is defined any differently for this so I am inclined to leave it in for now. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Aug 23 15:33:16 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 23 Aug 2016 15:33:16 +0000 Subject: [9] RFR(S): 8164649: Cleanup of test java/nio/channels/FileChannel/Lock.java Message-ID: <8fd2fbecbe3c495598a198d5da68ebca@DEWDFE13DE11.global.corp.sap> Hi, can I get a review for a test cleanup that I've made: https://bugs.openjdk.java.net/browse/JDK-8164649 http://cr.openjdk.java.net/~clanger/webrevs/8164649.1/ I was looking for a test that could reproduce the issue of https://bugs.openjdk.java.net/browse/JDK-7146506 on AIX and found that this test case inherently tests that bug as well. So I added a tag and found some other potential for cleaning it up and making it a bit more straightforward to understand :) But the behavior of the test itself should not have changed. Thanks & best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.smotrakov at oracle.com Tue Aug 23 20:16:06 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 23 Aug 2016 13:16:06 -0700 Subject: [9] RFR: 8164166: Make sure java/nio/channels tests shutdown asynchronous channel groups In-Reply-To: <4cda047f-7b23-b3a1-885c-d3c0180d3d87@oracle.com> References: <194a8062-6187-3bc4-c7a2-06f7f45a348c@oracle.com> <4cda047f-7b23-b3a1-885c-d3c0180d3d87@oracle.com> Message-ID: <69e2930c-f2e8-93ca-393b-5c0c77420c4a@oracle.com> Thank you for review Alan. Please see inline. On 08/23/2016 02:50 AM, Alan Bateman wrote: > On 23/08/2016 01:28, Artem Smotrakov wrote: > >> : >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164166 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8164166/webrev.00/ > For test/java/nio/channels/AsynchronousChannelGroup/Basic.java then it > would be a lot cleaner to put the cleanup in shutdownTests, e.g.: > > AsynchronousChannelGroup group = ... > try { > testShutdownWithNoChannels(pool, group); > } finally { > group.shutdown(); > } testShutdownWithNoChannels() method calls group.shutdown() right away, so that it doesn't look necessary to use try-finally block here. I added try-finally blocks to testShutdownWithChannels() and testShutdownNow() methods to reduce a number of try-finally blocks. I can wrap each call of testShutdownWithChannels() and testShutdownNow() methods to try-finally block if you think it is cleaner. > > In GroupOfOne then L47-49 isn't early to read. If you move the bind > into the try-finally, as in: listener.bind(new InetSocketAddress(0))) > then it would be a bit easier. Same comment for the changes to > Identify and testRestart in Restart.java. Okay, I'll split it. > > In testRestart then it looks like the try is in the wrong place, I > assume you want: > > group = ... > try { > testRestart(...) > } finally { > group.shutdown(); > } Right. I'll change it. Here is an updated webrev http://cr.openjdk.java.net/~asmotrak/8164166/webrev.01/ Artem > > -Alan > > > From Alan.Bateman at oracle.com Wed Aug 24 16:29:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Aug 2016 17:29:30 +0100 Subject: [9] RFR: 8164166: Make sure java/nio/channels tests shutdown asynchronous channel groups In-Reply-To: <69e2930c-f2e8-93ca-393b-5c0c77420c4a@oracle.com> References: <194a8062-6187-3bc4-c7a2-06f7f45a348c@oracle.com> <4cda047f-7b23-b3a1-885c-d3c0180d3d87@oracle.com> <69e2930c-f2e8-93ca-393b-5c0c77420c4a@oracle.com> Message-ID: On 23/08/2016 21:16, Artem Smotrakov wrote: > : > > Here is an updated webrev > > http://cr.openjdk.java.net/~asmotrak/8164166/webrev.01/ This looks much better. I think I would drop the comments at L125-128 and L287-290 as they don't add anything. -Alan From Alan.Bateman at oracle.com Wed Aug 24 16:46:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Aug 2016 17:46:11 +0100 Subject: [9] RFR(S): 8164649: Cleanup of test java/nio/channels/FileChannel/Lock.java In-Reply-To: <8fd2fbecbe3c495598a198d5da68ebca@DEWDFE13DE11.global.corp.sap> References: <8fd2fbecbe3c495598a198d5da68ebca@DEWDFE13DE11.global.corp.sap> Message-ID: On 23/08/2016 16:33, Langer, Christoph wrote: > > Hi, > > can I get a review for a test cleanup that I?ve made: > > https://bugs.openjdk.java.net/browse/JDK-8164649 > > http://cr.openjdk.java.net/~clanger/webrevs/8164649.1/ > > > I was looking for a test that could reproduce the issue of > https://bugs.openjdk.java.net/browse/JDK-7146506 on AIX and found that > this test case inherently tests that bug as well. So I added a tag and > found some other potential for cleaning it up and making it a bit more > straightforward to understand JBut the behavior of the test itself > should not have changed. > > No objection to updating this old test to use try-with-resources but I think needs a bit of formatting clean-up before pushing this. attemptLock - can "fos" be changed "raf". Also if the original File f were retained then it will be much easier to read as: File f = new File(s); try (RandomAccessFile raf = new RandomAccessFile(f, "rw")) { : } The FileChannel can then be obtained inside the block. test4 looks fine test3 looks fine. test2 looks fine. test1 looks a bit messy, L89-90 in particular. Also L118 switches to /* */ comments when // is used elsewhere. Also L65 makes it hard to see where the code in the try-finally is, it's inconsistent with the other tests. That's all I have, no semantics issues. -Alan test2 looks fine. test3 looks fine. L89 and L65 is an example where it's hard to see where the block starts. The other methods are easier to read. L89 is really oddly formatted. L89 L65 - very hard to see where the method starts so a blank line or put the { on the next line should make it easier to read. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Aug 24 19:12:49 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Aug 2016 20:12:49 +0100 Subject: 8066943: (fs) Path.relativize() gives incorrect result for ".." Message-ID: The relativize method has been problematic for sometime when used with paths containing "." or "..". Normalizing the paths first will make it work for most cases but there are corner cases that are still not right. The following patch updates the implementations to do the right thing. http://cr.openjdk.java.net/~alanb/8066943/webrev/ The bulk of the changes are new tests to make sure that all the cases are covered. -Alan From pavel.rappo at oracle.com Wed Aug 24 19:28:24 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 24 Aug 2016 20:28:24 +0100 Subject: 8066943: (fs) Path.relativize() gives incorrect result for ".." In-Reply-To: References: Message-ID: Hi Alan, You don't like "for" loops, do you? :-) for (int i = 0; i < getNameCount(); i++) { ... } instead of: int n = getNameCount(); int i = 0; while (i < n) { ... i++; } I'm looking forward to update to the latest TestNg or (to providing a similar functionality in our test library). When things like: try { Path result = path.relativize(that); out.format("\tExpected: IllegalArgumentException"); out.format("\tActual: %s\n", result); fail(); } catch (IllegalArgumentException expected) { } will become something like: assertThrows(IllegalArgumentException.class () -> path.relativize(that)); P.S. Looks good to me! Thanks. > On 24 Aug 2016, at 20:12, Alan Bateman wrote: > > The relativize method has been problematic for sometime when used with paths containing "." or "..". Normalizing the paths first will make it work for most cases but there are corner cases that are still not right. The following patch updates the implementations to do the right thing. > > http://cr.openjdk.java.net/~alanb/8066943/webrev/ > > The bulk of the changes are new tests to make sure that all the cases are covered. > > -Alan > From Alan.Bateman at oracle.com Wed Aug 24 19:31:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Aug 2016 20:31:14 +0100 Subject: 8066943: (fs) Path.relativize() gives incorrect result for ".." In-Reply-To: References: Message-ID: <7ed76623-5926-e87e-2034-eab89c53f2e9@oracle.com> On 24/08/2016 20:28, Pavel Rappo wrote: > Hi Alan, > > You don't like "for" loops, do you? :-) > > for (int i = 0; i < getNameCount(); i++) { > ... > } > > instead of: > > int n = getNameCount(); > int i = 0; > while (i < n) { > ... > i++; > } > You are right for the loop in hasDotOrDotDot, I'll fix that. But the other loops use i outside of the loop. -Alan From brian.burkhalter at oracle.com Wed Aug 24 20:04:13 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 24 Aug 2016 13:04:13 -0700 Subject: 8066943: (fs) Path.relativize() gives incorrect result for ".." In-Reply-To: <7ed76623-5926-e87e-2034-eab89c53f2e9@oracle.com> References: <7ed76623-5926-e87e-2034-eab89c53f2e9@oracle.com> Message-ID: On Aug 24, 2016, at 12:31 PM, Alan Bateman wrote: >> You don't like "for" loops, do you? :-) >> >> for (int i = 0; i < getNameCount(); i++) { >> ... >> } >> instead of: >> >> int n = getNameCount(); >> int i = 0; >> while (i < n) { >> ... >> i++; >> } >> > You are right for the loop in hasDotOrDotDot, I'll fix that. But the other loops use i outside of the loop. I think this looks good subsequent to the aforementioned change. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Aug 24 22:11:58 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Aug 2016 22:11:58 +0000 Subject: [9] RFR(S): 8164649: Cleanup of test java/nio/channels/FileChannel/Lock.java In-Reply-To: References: <8fd2fbecbe3c495598a198d5da68ebca@DEWDFE13DE11.global.corp.sap> Message-ID: <833989870eb246e4a415390801e4be83@DEWDFE13DE11.global.corp.sap> Hi Alan, thanks for looking into this. See my new vebrev: http://cr.openjdk.java.net/~clanger/webrevs/8164649.2/ I've implemented all suggestions, except for line 89 where I don't know how it should be done better... Thanks Christoph From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Mittwoch, 24. August 2016 18:46 To: Langer, Christoph ; nio-dev at openjdk.java.net Subject: Re: [9] RFR(S): 8164649: Cleanup of test java/nio/channels/FileChannel/Lock.java On 23/08/2016 16:33, Langer, Christoph wrote: Hi, can I get a review for a test cleanup that I've made: https://bugs.openjdk.java.net/browse/JDK-8164649 http://cr.openjdk.java.net/~clanger/webrevs/8164649.1/ I was looking for a test that could reproduce the issue of https://bugs.openjdk.java.net/browse/JDK-7146506 on AIX and found that this test case inherently tests that bug as well. So I added a tag and found some other potential for cleaning it up and making it a bit more straightforward to understand :) But the behavior of the test itself should not have changed. No objection to updating this old test to use try-with-resources but I think needs a bit of formatting clean-up before pushing this. attemptLock - can "fos" be changed "raf". Also if the original File f were retained then it will be much easier to read as: File f = new File(s); try (RandomAccessFile raf = new RandomAccessFile(f, "rw")) { : } The FileChannel can then be obtained inside the block. test4 looks fine test3 looks fine. test2 looks fine. test1 looks a bit messy, L89-90 in particular. Also L118 switches to /* */ comments when // is used elsewhere. Also L65 makes it hard to see where the code in the try-finally is, it's inconsistent with the other tests. That's all I have, no semantics issues. -Alan test2 looks fine. test3 looks fine. L89 and L65 is an example where it's hard to see where the block starts. The other methods are easier to read. L89 is really oddly formatted. L89 L65 - very hard to see where the method starts so a blank line or put the { on the next line should make it easier to read. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Aug 25 19:58:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Aug 2016 20:58:22 +0100 Subject: [9] RFR(S): 8164649: Cleanup of test java/nio/channels/FileChannel/Lock.java In-Reply-To: <833989870eb246e4a415390801e4be83@DEWDFE13DE11.global.corp.sap> References: <8fd2fbecbe3c495598a198d5da68ebca@DEWDFE13DE11.global.corp.sap> <833989870eb246e4a415390801e4be83@DEWDFE13DE11.global.corp.sap> Message-ID: <2fc28d90-876e-eb58-d005-a9deb4e22e97@oracle.com> On 24/08/2016 23:11, Langer, Christoph wrote: > Hi Alan, > > thanks for looking into this. > > See my new vebrev: > http://cr.openjdk.java.net/~clanger/webrevs/8164649.2/ > > > I?ve implemented all suggestions, except for line 89 where I don?t > know how it should be done better? > > Thanks for this, it looks much cleaned now. For L89 and L102 then you could split it into two statements to about the break - but what you have is okay, it's not worth spending time on. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Aug 29 09:33:52 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Aug 2016 09:33:52 +0000 Subject: [9] RFR(S): 8164649: Cleanup of test java/nio/channels/FileChannel/Lock.java In-Reply-To: <2fc28d90-876e-eb58-d005-a9deb4e22e97@oracle.com> References: <8fd2fbecbe3c495598a198d5da68ebca@DEWDFE13DE11.global.corp.sap> <833989870eb246e4a415390801e4be83@DEWDFE13DE11.global.corp.sap> <2fc28d90-876e-eb58-d005-a9deb4e22e97@oracle.com> Message-ID: Hi Alan, the change is pushed now: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2c68a91dcecf I have split lines 89 and 102 into two statements - hope this is more to your like. It's really hard to do that while keeping the 80 columns per line limit... Thanks again and best regards Christoph From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Donnerstag, 25. August 2016 21:58 To: Langer, Christoph ; nio-dev at openjdk.java.net Subject: Re: [9] RFR(S): 8164649: Cleanup of test java/nio/channels/FileChannel/Lock.java On 24/08/2016 23:11, Langer, Christoph wrote: Hi Alan, thanks for looking into this. See my new vebrev: http://cr.openjdk.java.net/~clanger/webrevs/8164649.2/ I've implemented all suggestions, except for line 89 where I don't know how it should be done better... Thanks for this, it looks much cleaned now. For L89 and L102 then you could split it into two statements to about the break - but what you have is okay, it's not worth spending time on. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.yuan at oracle.com Wed Aug 31 01:18:29 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 31 Aug 2016 09:18:29 +0800 Subject: JDK-8054039 Deadlock during interrupting FileChannel In-Reply-To: <029e01d1fcee$0cd97950$268c6bf0$@oracle.com> References: <00fe01d08bd0$6314f280$293ed780$@oracle.com> <5550803B.50203@oracle.com> <24497227-B196-4F23-A84E-F51839F83D88@oracle.com> <00e201d098ef$2a7dfd50$7f79f7f0$@oracle.com> <01f501d0c51b$9b6d3a00$d247ae00$@oracle.com> <55B09C61.6000005@oracle.com> <012c01d0ea1b$74666ab0$5d334010$@oracle.com> <9E67E71D-4861-4B5C-868C-BDE0878E3533@oracle.com> <023401d0ead5$73d818e0$5b884aa0$@oracle.com> <3C7C5557-378D-49A9-82FD-5032018C87C8@oracle.com> <034801d0eba7$b1448d30$13cda790$@oracle.com> <021f01d1f871$1f8a1130$5e9e3390$@oracle.com> <029e01d1fcee$0cd97950$268c6bf0$@oracle.com> Message-ID: <058d01d20325$98ff57f0$cafe07d0$@oracle.com> Hi Brian and Daniel Any comment or any concern for this patch? Thanks Frank From: Frank Yuan [mailto:frank.yuan at oracle.com] Sent: Tuesday, August 23, 2016 11:26 AM To: 'Brian Burkhalter'; 'Daniel Fuchs'; 'nio-dev' Subject: RE: JDK-8054039 Deadlock during interrupting FileChannel Does anybody have any comments? Frank From: Frank Yuan [mailto:frank.yuan at oracle.com] Sent: Wednesday, August 17, 2016 6:21 PM To: 'Brian Burkhalter'; 'Daniel Fuchs'; 'nio-dev' Subject: RE: JDK-8054039 Deadlock during interrupting FileChannel Hi I reclaimed this task after a long time of suspending(really sorry for that.) However, I am sure for the fix now, that is the solution 1 which we talked about. I made an update for the latest code, would you like to check again: http://cr.openjdk.java.net/~fyuan/8054039/webrev.00/ ? As you known, this failure scenario is like: Thread 1 hold blockerLock of thread 2 and try to hold closeLock of FileChannel 1 Thread 2 hold closeLock of FileChannel 1 and try to hold blockerLock of thread 2, i.e. its own thread To solve the deadlock, this patch won't try to hold blockerLock of current thread in FileChannel, look at the change in NativeThreadSet.java if (interrupted) - Thread.currentThread().interrupt(); + SharedSecrets.getJavaLangAccess().doInterrupt(Thread.currentThread()); } Here, it only need to set the interrupted flag, doesn't need to call Interruptible.interrupt() extra, because either .interrupt() will call it(since current thread is already interrupted its interrupt method must be already invoked) or the AbstractInterruptibleChannel object will call it in the begin method(because we have set the interrupted flag again) if current thread has an Interruptible object. Btw, I am not sure if we need to add any note in the comment of AbstractInterruptibleChannel.implCloseChannel() to state the implementation must avoid to call interrupt method of current thread. Thanks Frank From: Frank Yuan [mailto:frank.yuan at oracle.com] Sent: Thursday, September 10, 2015 5:04 PM To: 'Brian Burkhalter'; 'nio-dev' Cc: 'FELIX YANG' Subject: RE: JDK-8054039 Deadlock during interrupting FileChannel Hi Frank, On Sep 9, 2015, at 12:59 AM, Frank Yuan > wrote: Thank you for review and your comments:) You are welcome. The size of my last mail is too large, is still held by maillist moderator, I have to send some content again(the diagram still can't be attached.). You could upload the diagram and a webrev to cr.openjdk.java.net assuming you have an ID. If not, I could do it for you. I have uploaded the diagram to the bug https://bugs.openjdk.java.net/browse/JDK-8054039, hope more people can review it. I am suspicious of the use of reflection here. I also have some concern for this solution, because in this fix nio will depend on the private method of Thread -- interrupt0, it will break the encapsulation. However it's an available solution in theory. True but I think the second one is better. Within the scope of AbstractInterruptibleChannel I do not see any problem with the change that you propose. Given that the affected instance variables are private to the class and that AtomicBoolean "generally" follows the rules for volatiles it looks conceptually valid. I do not know however about the implications with respect to interactions with other classes. For example, could this change provoke some unforeseen behavior as a result of subtle changes in timing? As my understood, this solution won't spend more time on begin() than the old code, compareAndSet is atomic and there is no loop or wait. Anyway I am not sure your concern, will do more tests, hope more people can review it. Indeed I don't know whether there would be any effect: it was simply an observation. I expect others will comment when they have time. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Aug 31 20:49:02 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 31 Aug 2016 13:49:02 -0700 Subject: JDK 9 RFR of 8165000: Selector.select(timeout) throws IOException when timeout is a large long Message-ID: <2EB7AC83-5376-44F8-8F21-CFDBE90D4070@oracle.com> 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/ManPages_iPhoneOS/man2/kevent.2.html