From amy.lu at oracle.com Thu Jun 1 03:20:37 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 1 Jun 2017 11:20:37 +0800 Subject: JDK 10 RFR of JDK-8181301: Refactor shell test AsynchronousChannelGroup/run_any_task.sh to java In-Reply-To: References: <1890eba3-8030-3ca6-ef5a-3e381c977eac@oracle.com> <99f549ea-c64c-6994-48e2-e17c078274a8@oracle.com> Message-ID: <8b4a5415-ecc1-36a7-6609-67513f021120@oracle.com> On 5/31/17 4:39 PM, Alan Bateman wrote: > On 31/05/2017 09:10, Amy Lu wrote: > >> Thank you Alan! >> >> Webrev updated according to the suggestions: >> http://cr.openjdk.java.net/~amlu/8181301/webrev.01 >> > Looks good. Thank you. Pushed. /Amy From amy.lu at oracle.com Thu Jun 1 06:45:40 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 1 Jun 2017 14:45:40 +0800 Subject: JDK 10 RFR of JDK-8181393: Refactor shell test Selector/lots_of_updates.sh and SocketChannel/Open.sh to java Message-ID: java/nio/channels/Selector/lots_of_updates.sh java/nio/channels/SocketChannel/Open.java which runs shell test: * @run shell Open.sh Please review this patch to refactor above shell tests to java. bug: https://bugs.openjdk.java.net/browse/JDK-8181393 webrev: http://cr.openjdk.java.net/~amlu/8181393/webrev.00/ Thanks, Amy From amy.lu at oracle.com Thu Jun 1 10:22:48 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 1 Jun 2017 18:22:48 +0800 Subject: JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java Message-ID: java/nio/file/Files/walkFileTree/find.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8181394 webrev: http://cr.openjdk.java.net/~amlu/8181394/webrev.00/ (I'll add @build jdk.test.lib.process.* if this is the "best" workaround of CODETOOLS-7901986) Thanks, Amy From Alan.Bateman at oracle.com Thu Jun 1 10:51:36 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Jun 2017 11:51:36 +0100 Subject: JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java In-Reply-To: References: Message-ID: <01bb3ec2-8854-b8c0-d5ee-b8b830aa3d68@oracle.com> On 01/06/2017 11:22, Amy Lu wrote: > java/nio/file/Files/walkFileTree/find.sh > > Please review this patch to refactor the shell test to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8181394 > webrev: http://cr.openjdk.java.net/~amlu/8181394/webrev.00/ > > (I'll add @build jdk.test.lib.process.* if this is the "best" > workaround of CODETOOLS-7901986) I think it would be cleaner if you merged FindTest, CreateFileTree and PrintFileTree. That should eliminate the need to launch PrintFileTree in its own VM, it would make the test setup simpler too. Also it would be nice to avoid SerializationUtils too. -Alan From paul.sandoz at oracle.com Fri Jun 2 20:21:15 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 2 Jun 2017 13:21:15 -0700 Subject: JDK 10 RFR of JDK-8181393: Refactor shell test Selector/lots_of_updates.sh and SocketChannel/Open.sh to java In-Reply-To: References: Message-ID: <549893D1-1B02-4060-8D0F-196A05D67689@oracle.com> > On 31 May 2017, at 23:45, Amy Lu wrote: > > java/nio/channels/Selector/lots_of_updates.sh > java/nio/channels/SocketChannel/Open.java which runs shell test: > * @run shell Open.sh > > Please review this patch to refactor above shell tests to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8181393 > webrev: http://cr.openjdk.java.net/~amlu/8181393/webrev.00/ > +1 Out of curiosity is jtreg compilation of a test smart enough to know of at least some of its dependencies. 24 /* 25 * @test 26 * @bug 6824477 27 * @summary Selector.select can fail with IOException "Invalid argument" on 28 * Solaris if maximum number of file descriptors is less than 10000 29 * @requires (os.family != "windows") 30 * @library /test/lib 31 * @build LotsOfUpdates 32 * @run main LotsOfUpdatesTest 33 */ 34 35 import jdk.test.lib.process.ProcessTools; 36 37 public class LotsOfUpdatesTest { Do you require line 31 since LotsOfUpdatesTest refers directly to LotsOfUpdates? Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From amy.lu at oracle.com Mon Jun 5 06:22:03 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 5 Jun 2017 14:22:03 +0800 Subject: JDK 10 RFR of JDK-8181393: Refactor shell test Selector/lots_of_updates.sh and SocketChannel/Open.sh to java In-Reply-To: <549893D1-1B02-4060-8D0F-196A05D67689@oracle.com> References: <549893D1-1B02-4060-8D0F-196A05D67689@oracle.com> Message-ID: <1a0c3e01-f9ea-0db3-4a8c-cdcfa9a2f60e@oracle.com> On 6/3/17 4:21 AM, Paul Sandoz wrote: >> webrev: http://cr.openjdk.java.net/~amlu/8181393/webrev.00/ >> >> > > +1 > > Out of curiosity is jtreg compilation of a test smart enough to know > of at least some of its dependencies. > > 24 /* > 25 * @test > 26 * @bug 6824477 > 27 * @summary Selector.select can fail with IOException "Invalid argument" on > 28 * Solaris if maximum number of file descriptors is less than 10000 > 29 * @requires (os.family != "windows") > 30 * @library /test/lib > 31 * @build LotsOfUpdates > 32 * @run main LotsOfUpdatesTest > 33 */ > 34 > 35 import jdk.test.lib.process.ProcessTools; > 36 > 37 public class LotsOfUpdatesTest { > Do you require line 31 since LotsOfUpdatesTest refers directly to > LotsOfUpdates? Actually test works fine without line 31 because it refers as LotsOfUpdates.class.getName() (instead of a String "LotsOfUpdates"). I still want the at build in this case just to indicate explicitly that the test has dependency other than @library Thank you Paul for reviewing. Pushed. Thanks, Amy -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Mon Jun 5 06:26:20 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 5 Jun 2017 14:26:20 +0800 Subject: JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java In-Reply-To: <01bb3ec2-8854-b8c0-d5ee-b8b830aa3d68@oracle.com> References: <01bb3ec2-8854-b8c0-d5ee-b8b830aa3d68@oracle.com> Message-ID: Please review the updated webrev: http://cr.openjdk.java.net/~amlu/8181394/webrev.01 CreateFileTree is also used by other tests, no change. Thanks, Amy On 6/1/17 6:51 PM, Alan Bateman wrote: >> webrev: http://cr.openjdk.java.net/~amlu/8181394/webrev.00/ > I think it would be cleaner if you merged FindTest, CreateFileTree and > PrintFileTree. That should eliminate the need to launch PrintFileTree > in its own VM, it would make the test setup simpler too. Also it would > be nice to avoid SerializationUtils too. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Mon Jun 5 06:54:11 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 5 Jun 2017 14:54:11 +0800 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java Message-ID: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> java/nio/file/Files/delete_on_close.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8181396 webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ Thanks, Amy From Alan.Bateman at oracle.com Mon Jun 5 14:47:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Jun 2017 15:47:52 +0100 Subject: JDK 10 RFR of JDK-8181393: Refactor shell test Selector/lots_of_updates.sh and SocketChannel/Open.sh to java In-Reply-To: References: Message-ID: On 01/06/2017 07:45, Amy Lu wrote: > java/nio/channels/Selector/lots_of_updates.sh > java/nio/channels/SocketChannel/Open.java which runs shell test: > * @run shell Open.sh > > Please review this patch to refactor above shell tests to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8181393 > webrev: http://cr.openjdk.java.net/~amlu/8181393/webrev.00/ Looks okay except for a minor nit in the comments "//hard limit" which a space is missing. -Alan From Alan.Bateman at oracle.com Mon Jun 5 14:52:08 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Jun 2017 15:52:08 +0100 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java In-Reply-To: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> References: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> Message-ID: <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> On 05/06/2017 07:54, Amy Lu wrote: > java/nio/file/Files/delete_on_close.sh > > Please review this patch to refactor the shell test to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8181396 > webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ I think it's a bit confusing to have both DeleteOnClose and DeleteOnTerminate, esp. when DeleteOnTerminate creates a file with DELETE_ON_CLOSE. Instead couldn't DeleteOnClose just launch itself to create the file? -Alan From amy.lu at oracle.com Mon Jun 5 16:11:41 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 6 Jun 2017 00:11:41 +0800 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java In-Reply-To: <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> References: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> Message-ID: <238ff235-0e4d-8889-32f1-753ffadf0a5f@oracle.com> Good point! Please review the updated version: http://cr.openjdk.java.net/~amlu/8181396/webrev.01 Thanks, Amy On 6/5/17 10:52 PM, Alan Bateman wrote: > On 05/06/2017 07:54, Amy Lu wrote: >> java/nio/file/Files/delete_on_close.sh >> >> Please review this patch to refactor the shell test to java. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8181396 >> webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ > I think it's a bit confusing to have both DeleteOnClose and > DeleteOnTerminate, esp. when DeleteOnTerminate creates a file with > DELETE_ON_CLOSE. Instead couldn't DeleteOnClose just launch itself to > create the file? > > -Alan From amy.lu at oracle.com Mon Jun 5 18:03:24 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 6 Jun 2017 02:03:24 +0800 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java In-Reply-To: <238ff235-0e4d-8889-32f1-753ffadf0a5f@oracle.com> References: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> <238ff235-0e4d-8889-32f1-753ffadf0a5f@oracle.com> Message-ID: <5baf0281-67e3-a0e3-e88f-99320d3f2b5c@oracle.com> On 6/6/17 12:11 AM, Amy Lu wrote: > Good point! > > Please review the updated version: > http://cr.openjdk.java.net/~amlu/8181396/webrev.01 Sorry, I have to withdraw this version. Somehow this does not work on Windows, the created blah*tmp will not be deleted until the launched DeleteOnClose (by itself) also exit. (webrev.00 works fine.) Thanks, Amy > > Thanks, > Amy > > On 6/5/17 10:52 PM, Alan Bateman wrote: >> On 05/06/2017 07:54, Amy Lu wrote: >>> java/nio/file/Files/delete_on_close.sh >>> >>> Please review this patch to refactor the shell test to java. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8181396 >>> webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ >> I think it's a bit confusing to have both DeleteOnClose and >> DeleteOnTerminate, esp. when DeleteOnTerminate creates a file with >> DELETE_ON_CLOSE. Instead couldn't DeleteOnClose just launch itself to >> create the file? >> >> -Alan > From amy.lu at oracle.com Tue Jun 6 01:34:51 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 6 Jun 2017 09:34:51 +0800 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java In-Reply-To: <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> References: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> Message-ID: On 6/5/17 10:52 PM, Alan Bateman wrote: >> webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ > I think it's a bit confusing to have both DeleteOnClose and > DeleteOnTerminate, esp. when DeleteOnTerminate creates a file with > DELETE_ON_CLOSE. Instead couldn't DeleteOnClose just launch itself to > create the file? Please review the updated webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.02/ Tested on all platforms. Thanks, Amy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jun 6 07:46:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 6 Jun 2017 08:46:52 +0100 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java In-Reply-To: References: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> Message-ID: <70f6f3f7-6fed-4edd-e1ff-786eebcd12a5@oracle.com> On 06/06/2017 02:34, Amy Lu wrote: > On 6/5/17 10:52 PM, Alan Bateman wrote: >>> webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ >> I think it's a bit confusing to have both DeleteOnClose and >> DeleteOnTerminate, esp. when DeleteOnTerminate creates a file with >> DELETE_ON_CLOSE. Instead couldn't DeleteOnClose just launch itself to >> create the file? > > Please review the updated webrev: > http://cr.openjdk.java.net/~amlu/8181396/webrev.02/ > This looks okay except for "/java/nio/file" in the @library value - I assume that is not needed. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Tue Jun 6 08:48:27 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 6 Jun 2017 16:48:27 +0800 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java In-Reply-To: <70f6f3f7-6fed-4edd-e1ff-786eebcd12a5@oracle.com> References: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> <70f6f3f7-6fed-4edd-e1ff-786eebcd12a5@oracle.com> Message-ID: On 6/6/17 3:46 PM, Alan Bateman wrote: > > > On 06/06/2017 02:34, Amy Lu wrote: >> On 6/5/17 10:52 PM, Alan Bateman wrote: >>>> webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ >>> I think it's a bit confusing to have both DeleteOnClose and >>> DeleteOnTerminate, esp. when DeleteOnTerminate creates a file with >>> DELETE_ON_CLOSE. Instead couldn't DeleteOnClose just launch itself >>> to create the file? >> >> Please review the updated webrev: >> http://cr.openjdk.java.net/~amlu/8181396/webrev.02/ >> > This looks okay except for "/java/nio/file" in the @library value - I > assume that is not needed. This is for ../TestUtil.java, which is jdk/test/java/nio/file/TestUtil.java Thank you for reviewing. Thanks, Amy > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jun 6 09:03:01 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 6 Jun 2017 10:03:01 +0100 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java In-Reply-To: References: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> <70f6f3f7-6fed-4edd-e1ff-786eebcd12a5@oracle.com> Message-ID: <4575a594-11c2-f0b0-ba22-07ccf01c22ad@oracle.com> On 06/06/2017 09:48, Amy Lu wrote: > On 6/6/17 3:46 PM, Alan Bateman wrote: >> >> >> On 06/06/2017 02:34, Amy Lu wrote: >>> On 6/5/17 10:52 PM, Alan Bateman wrote: >>>>> webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/ >>>> I think it's a bit confusing to have both DeleteOnClose and >>>> DeleteOnTerminate, esp. when DeleteOnTerminate creates a file with >>>> DELETE_ON_CLOSE. Instead couldn't DeleteOnClose just launch itself >>>> to create the file? >>> >>> Please review the updated webrev: >>> http://cr.openjdk.java.net/~amlu/8181396/webrev.02/ >>> >> This looks okay except for "/java/nio/file" in the @library value - I >> assume that is not needed. > This is for ../TestUtil.java, which is > jdk/test/java/nio/file/TestUtil.java > Okay although TestUtil is not general infrastructure, this is why the other tests use "..". -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jun 6 13:49:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 6 Jun 2017 14:49:19 +0100 Subject: JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java In-Reply-To: References: <01bb3ec2-8854-b8c0-d5ee-b8b830aa3d68@oracle.com> Message-ID: <72aa2ae5-d19c-5c61-b060-6c88ac496dd7@oracle.com> On 05/06/2017 07:26, Amy Lu wrote: > Please review the updated webrev: > http://cr.openjdk.java.net/~amlu/8181394/webrev.01 > > CreateFileTree is also used by other tests, no change. > This looks much better. At some point we might decide to remove the cleanUp method as it can often be useful to leave the file tree around, esp. if there is a test failure. -Alan From amy.lu at oracle.com Wed Jun 7 03:01:18 2017 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 7 Jun 2017 11:01:18 +0800 Subject: JDK 10 RFR of JDK-8181396: Refactor shell test java/nio/file/Files/delete_on_close.sh to java In-Reply-To: <4575a594-11c2-f0b0-ba22-07ccf01c22ad@oracle.com> References: <8e0e0a81-fce5-ba11-ab2c-cbea0d5b6135@oracle.com> <77f166d0-5a37-e9ef-b9df-be8b5c20a217@oracle.com> <70f6f3f7-6fed-4edd-e1ff-786eebcd12a5@oracle.com> <4575a594-11c2-f0b0-ba22-07ccf01c22ad@oracle.com> Message-ID: <99d02598-6e34-3a70-9a44-acf9a489e3c8@oracle.com> On 6/6/17 5:03 PM, Alan Bateman wrote: >>>> http://cr.openjdk.java.net/~amlu/8181396/webrev.02/ >>>> >>> This looks okay except for "/java/nio/file" in the @library value - >>> I assume that is not needed. >> This is for ../TestUtil.java, which is >> jdk/test/java/nio/file/TestUtil.java >> > Okay although TestUtil is not general infrastructure, this is why the > other tests use "..". Thank you Alan. Pushed with changed back to ".." Thanks, Amy -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Wed Jun 7 03:04:43 2017 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 7 Jun 2017 11:04:43 +0800 Subject: JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java In-Reply-To: <72aa2ae5-d19c-5c61-b060-6c88ac496dd7@oracle.com> References: <01bb3ec2-8854-b8c0-d5ee-b8b830aa3d68@oracle.com> <72aa2ae5-d19c-5c61-b060-6c88ac496dd7@oracle.com> Message-ID: <70469e58-a683-7b95-17c2-9ded712bb27d@oracle.com> On 6/6/17 9:49 PM, Alan Bateman wrote: >> http://cr.openjdk.java.net/~amlu/8181394/webrev.01 >> >> CreateFileTree is also used by other tests, no change. >> > This looks much better. At some point we might decide to remove the > cleanUp method as it can often be useful to leave the file tree > around, esp. if there is a test failure. Got your point, let me do this change in this patch. Please review: http://cr.openjdk.java.net/~amlu/8181394/webrev.02/ ( For your reference: http://cr.openjdk.java.net/~amlu/8181394/FindTest.webrev.01_webrev.02.diff ) Thanks, Amy -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Wed Jun 7 06:14:42 2017 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 7 Jun 2017 14:14:42 +0800 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java Message-ID: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> java/nio/charset/Charset/default.sh java/nio/charset/coders/CheckSJISMappingProp.sh java/nio/file/Path/MacPathTest.java which runs shell test: * @run shell MacPathTest.sh Please review this patch to refactor these shell tests to java. Note that in MacPathTest.sh, it requires the test to be run with LC_ALL=en_US.UTF-8 env. But unlike the other two tests, LC_ALL settings here is just to setup an env in order for the test to work correctly, it?s not the locale it intends to test. bug: https://bugs.openjdk.java.net/browse/JDK-8181395 webrev: http://cr.openjdk.java.net/~amlu/8181395/webrev.00/ Thanks, Amy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jun 7 14:21:13 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Jun 2017 15:21:13 +0100 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> Message-ID: On 07/06/2017 07:14, Amy Lu wrote: > java/nio/charset/Charset/default.sh > java/nio/charset/coders/CheckSJISMappingProp.sh > java/nio/file/Path/MacPathTest.java which runs shell test: > * @run shell MacPathTest.sh > > Please review this patch to refactor these shell tests to java. > > Note that in MacPathTest.sh, it requires the test to be run with > LC_ALL=en_US.UTF-8 env. But unlike the other two tests, LC_ALL > settings here is just to setup an env in order for the test to work > correctly, it?s not the locale it intends to test. One thing that isn't clear to me is the value of UNSUPPORTED as I assume it will contain the value "nonexist" and so don't match when testing other locales that aren't installed. -Alan. From amy.lu at oracle.com Wed Jun 7 15:14:15 2017 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 7 Jun 2017 23:14:15 +0800 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> Message-ID: <133f96df-91cd-efb9-665d-d93ac1318a5a@oracle.com> On 6/7/17 10:21 PM, Alan Bateman wrote: > > > On 07/06/2017 07:14, Amy Lu wrote: >> java/nio/charset/Charset/default.sh >> java/nio/charset/coders/CheckSJISMappingProp.sh >> java/nio/file/Path/MacPathTest.java which runs shell test: >> * @run shell MacPathTest.sh >> >> Please review this patch to refactor these shell tests to java. >> >> Note that in MacPathTest.sh, it requires the test to be run with >> LC_ALL=en_US.UTF-8 env. But unlike the other two tests, LC_ALL >> settings here is just to setup an env in order for the test to work >> correctly, it?s not the locale it intends to test. > One thing that isn't clear to me is the value of UNSUPPORTED as I > assume it will contain the value "nonexist" and so don't match when > testing other locales that aren't installed. > > -Alan. Defaul.java System.out.println(Charset.defaultCharset()); The output for "nonexist" (not supported) LC_ALL is (at least on Solaris): US-ASCII The output is the same as set LC_ALL from commandline: $ export LC_ALL=nonexist bash: warning: setlocale: LC_ALL: cannot change locale (nonexist) $ echo $LC_ALL nonexist $ jdk/bin/java Default US-ASCII I'm not sure why though. Also not sure whether it's the same across platforms, settings. So I make it run with the "nonexist" locale to get the String UNSUPPORTED. Thanks, Amy From Alan.Bateman at oracle.com Thu Jun 8 14:48:11 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Jun 2017 15:48:11 +0100 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: <133f96df-91cd-efb9-665d-d93ac1318a5a@oracle.com> References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> <133f96df-91cd-efb9-665d-d93ac1318a5a@oracle.com> Message-ID: <478f4038-e767-902b-a6e7-3bed61e6acb6@oracle.com> On 07/06/2017 16:14, Amy Lu wrote: > Defaul.java > System.out.println(Charset.defaultCharset()); > > The output for "nonexist" (not supported) LC_ALL is (at least on > Solaris): US-ASCII > > The output is the same as set LC_ALL from commandline: > > $ export LC_ALL=nonexist > bash: warning: setlocale: LC_ALL: cannot change locale (nonexist) > > $ echo $LC_ALL > nonexist > > $ jdk/bin/java Default > US-ASCII > > I'm not sure why though. Also not sure whether it's the same across > platforms, settings. So I make it run with the "nonexist" locale to > get the String UNSUPPORTED. > I assume "US-ASCII" is coming from nl_langinfo(CODESET), at least on OSX/Linux/Solaris. I'm surprised that it prints "US-ASCII" on Windows but maybe that needs a system without the JP locales to prove that. -Alan. From amy.lu at oracle.com Thu Jun 8 16:46:36 2017 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 9 Jun 2017 00:46:36 +0800 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: <478f4038-e767-902b-a6e7-3bed61e6acb6@oracle.com> References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> <133f96df-91cd-efb9-665d-d93ac1318a5a@oracle.com> <478f4038-e767-902b-a6e7-3bed61e6acb6@oracle.com> Message-ID: <9b19f871-2e90-d191-6ff0-b6f8d9228b68@oracle.com> On 6/8/17 10:48 PM, Alan Bateman wrote: > On 07/06/2017 16:14, Amy Lu wrote: >> Defaul.java >> System.out.println(Charset.defaultCharset()); >> >> The output for "nonexist" (not supported) LC_ALL is (at least on >> Solaris): US-ASCII >> >> The output is the same as set LC_ALL from commandline: >> >> $ export LC_ALL=nonexist >> bash: warning: setlocale: LC_ALL: cannot change locale (nonexist) >> >> $ echo $LC_ALL >> nonexist >> >> $ jdk/bin/java Default >> US-ASCII >> >> I'm not sure why though. Also not sure whether it's the same across >> platforms, settings. So I make it run with the "nonexist" locale to >> get the String UNSUPPORTED. >> > I assume "US-ASCII" is coming from nl_langinfo(CODESET), at least on > OSX/Linux/Solaris. I'm surprised that it prints "US-ASCII" on Windows > but maybe that needs a system without the JP locales to prove that. This test won't run on Windows. DefaultCharsetTest.java @requires (os.family == "linux" | os.family == "solaris") which is from the original default.sh Maybe this test should be expanded to OSX, I can file a separate bug for this purpose (if needed). Thanks, Amy > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Fri Jun 9 02:14:40 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 9 Jun 2017 10:14:40 +0800 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> Message-ID: Hi Amy, For refactoring MacPathTest, I wonder if it's sufficient to just change below line? - * @run shell MacPathTest.sh + * @run main/othervm -Duser.language=en -Duser.country=US -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 MacPathTest */ Thank you -Hamlin On 2017/6/7 14:14, Amy Lu wrote: > java/nio/charset/Charset/default.sh > java/nio/charset/coders/CheckSJISMappingProp.sh > java/nio/file/Path/MacPathTest.java which runs shell test: > * @run shell MacPathTest.sh > > Please review this patch to refactor these shell tests to java. > > Note that in MacPathTest.sh, it requires the test to be run with > LC_ALL=en_US.UTF-8 env. But unlike the other two tests, LC_ALL > settings here is just to setup an env in order for the test to work > correctly, it?s not the locale it intends to test. > > bug: https://bugs.openjdk.java.net/browse/JDK-8181395 > webrev: http://cr.openjdk.java.net/~amlu/8181395/webrev.00/ > > Thanks, > Amy From amy.lu at oracle.com Fri Jun 9 03:10:14 2017 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 9 Jun 2017 11:10:14 +0800 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> Message-ID: Thank you Hamlin. I actually think -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 is enough. I added Locale.setDefault(Locale.US) and restore "just for safe". The encoding check (and warnings/usage) is mainly for helping one who tries to run it from command line. Thanks, Amy On 6/9/17 10:14 AM, Hamlin Li wrote: > Hi Amy, > > For refactoring MacPathTest, I wonder if it's sufficient to just > change below line? > > > - * @run shell MacPathTest.sh > + * @run main/othervm -Duser.language=en -Duser.country=US > -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 MacPathTest > */ > > Thank you > > -Hamlin > > > On 2017/6/7 14:14, Amy Lu wrote: >> java/nio/charset/Charset/default.sh >> java/nio/charset/coders/CheckSJISMappingProp.sh >> java/nio/file/Path/MacPathTest.java which runs shell test: >> * @run shell MacPathTest.sh >> >> Please review this patch to refactor these shell tests to java. >> >> Note that in MacPathTest.sh, it requires the test to be run with >> LC_ALL=en_US.UTF-8 env. But unlike the other two tests, LC_ALL >> settings here is just to setup an env in order for the test to work >> correctly, it?s not the locale it intends to test. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8181395 >> webrev: http://cr.openjdk.java.net/~amlu/8181395/webrev.00/ >> >> Thanks, >> Amy > From huaming.li at oracle.com Fri Jun 9 03:30:05 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 9 Jun 2017 11:30:05 +0800 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> Message-ID: Got it, thank you for explanation. Although I don't think it's necessary, it's harmless to add the check. Thank you -Hamlin On 2017/6/9 11:10, Amy Lu wrote: > Thank you Hamlin. > > I actually think -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 is > enough. I added Locale.setDefault(Locale.US) and restore "just for safe". > The encoding check (and warnings/usage) is mainly for helping one who > tries to run it from command line. > > Thanks, > Amy > > On 6/9/17 10:14 AM, Hamlin Li wrote: >> Hi Amy, >> >> For refactoring MacPathTest, I wonder if it's sufficient to just >> change below line? >> >> >> - * @run shell MacPathTest.sh >> + * @run main/othervm -Duser.language=en -Duser.country=US >> -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 MacPathTest >> */ >> >> Thank you >> >> -Hamlin >> >> >> On 2017/6/7 14:14, Amy Lu wrote: >>> java/nio/charset/Charset/default.sh >>> java/nio/charset/coders/CheckSJISMappingProp.sh >>> java/nio/file/Path/MacPathTest.java which runs shell test: >>> * @run shell MacPathTest.sh >>> >>> Please review this patch to refactor these shell tests to java. >>> >>> Note that in MacPathTest.sh, it requires the test to be run with >>> LC_ALL=en_US.UTF-8 env. But unlike the other two tests, LC_ALL >>> settings here is just to setup an env in order for the test to work >>> correctly, it?s not the locale it intends to test. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8181395 >>> webrev: http://cr.openjdk.java.net/~amlu/8181395/webrev.00/ >>> >>> Thanks, >>> Amy >> > From amy.lu at oracle.com Mon Jun 12 08:35:20 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 12 Jun 2017 16:35:20 +0800 Subject: JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java In-Reply-To: <70469e58-a683-7b95-17c2-9ded712bb27d@oracle.com> References: <01bb3ec2-8854-b8c0-d5ee-b8b830aa3d68@oracle.com> <72aa2ae5-d19c-5c61-b060-6c88ac496dd7@oracle.com> <70469e58-a683-7b95-17c2-9ded712bb27d@oracle.com> Message-ID: On 6/7/17 11:04 AM, Amy Lu wrote: > On 6/6/17 9:49 PM, Alan Bateman wrote: >>> http://cr.openjdk.java.net/~amlu/8181394/webrev.01 >>> >>> CreateFileTree is also used by other tests, no change. >>> >> This looks much better. At some point we might decide to remove the >> cleanUp method as it can often be useful to leave the file tree >> around, esp. if there is a test failure. > Got your point, let me do this change in this patch. > > Please review: http://cr.openjdk.java.net/~amlu/8181394/webrev.02/ > ( For your reference: > http://cr.openjdk.java.net/~amlu/8181394/FindTest.webrev.01_webrev.02.diff > ) Hi, Alan Is this fine to go? Thanks, Amy > > Thanks, > Amy -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Mon Jun 12 08:36:33 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 12 Jun 2017 16:36:33 +0800 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: <9b19f871-2e90-d191-6ff0-b6f8d9228b68@oracle.com> References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> <133f96df-91cd-efb9-665d-d93ac1318a5a@oracle.com> <478f4038-e767-902b-a6e7-3bed61e6acb6@oracle.com> <9b19f871-2e90-d191-6ff0-b6f8d9228b68@oracle.com> Message-ID: On 6/7/17 2:14 PM, Amy Lu wrote: > webrev: http://cr.openjdk.java.net/~amlu/8181395/webrev.00/ Hi, Alan Is this fine to go? Thanks, Amy On 6/9/17 12:46 AM, Amy Lu wrote: > On 6/8/17 10:48 PM, Alan Bateman wrote: >> On 07/06/2017 16:14, Amy Lu wrote: >>> Defaul.java >>> System.out.println(Charset.defaultCharset()); >>> >>> The output for "nonexist" (not supported) LC_ALL is (at least on >>> Solaris): US-ASCII >>> >>> The output is the same as set LC_ALL from commandline: >>> >>> $ export LC_ALL=nonexist >>> bash: warning: setlocale: LC_ALL: cannot change locale (nonexist) >>> >>> $ echo $LC_ALL >>> nonexist >>> >>> $ jdk/bin/java Default >>> US-ASCII >>> >>> I'm not sure why though. Also not sure whether it's the same across >>> platforms, settings. So I make it run with the "nonexist" locale to >>> get the String UNSUPPORTED. >>> >> I assume "US-ASCII" is coming from nl_langinfo(CODESET), at least on >> OSX/Linux/Solaris. I'm surprised that it prints "US-ASCII" on Windows >> but maybe that needs a system without the JP locales to prove that. > This test won't run on Windows. > > DefaultCharsetTest.java > @requires (os.family == "linux" | os.family == "solaris") > which is from the original default.sh > > Maybe this test should be expanded to OSX, I can file a separate bug > for this purpose (if needed). > > Thanks, > Amy >> >> -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jun 12 11:42:33 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Jun 2017 12:42:33 +0100 Subject: JDK 10 RFR of JDK-8181394: Refactor shell test java/nio/file/Files/walkFileTree/find.sh to java In-Reply-To: References: <01bb3ec2-8854-b8c0-d5ee-b8b830aa3d68@oracle.com> <72aa2ae5-d19c-5c61-b060-6c88ac496dd7@oracle.com> <70469e58-a683-7b95-17c2-9ded712bb27d@oracle.com> Message-ID: <5b95540b-e323-b661-7524-310730a15462@oracle.com> On 12/06/2017 09:35, Amy Lu wrote: > On 6/7/17 11:04 AM, Amy Lu wrote: >> On 6/6/17 9:49 PM, Alan Bateman wrote: >>>> http://cr.openjdk.java.net/~amlu/8181394/webrev.01 >>>> >>>> CreateFileTree is also used by other tests, no change. >>>> >>> This looks much better. At some point we might decide to remove the >>> cleanUp method as it can often be useful to leave the file tree >>> around, esp. if there is a test failure. >> Got your point, let me do this change in this patch. >> >> Please review: http://cr.openjdk.java.net/~amlu/8181394/webrev.02/ >> ( For your reference: >> http://cr.openjdk.java.net/~amlu/8181394/FindTest.webrev.01_webrev.02.diff >> ) > > Hi, Alan > > Is this fine to go? > Yes, I think the update version is good. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Wed Jun 14 13:35:21 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 14 Jun 2017 08:35:21 -0500 Subject: Bug in sun.nio.ch.SolarisEventPort#port_dissociate Message-ID: There's a bug in sun.nio.ch.SolarisEventPort#port_dissociate which manifests as an IOException like this: Exception in thread "default I/O-30" java.lang.InternalError: java.io.IOException: File descriptor in bad state at sun.nio.ch.EventPortWrapper.release(EventPortWrapper.java:235) at sun.nio.ch.EventPortSelectorImpl.implDereg(EventPortSelectorImpl.java:144) at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149) at sun.nio.ch.EventPortSelectorImpl.doSelect(EventPortSelectorImpl.java:75) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at org.xnio.nio.WorkerThread.run(WorkerThread.java:528) Caused by: java.io.IOException: File descriptor in bad state at sun.nio.ch.SolarisEventPort.port_dissociate(Native Method) at sun.nio.ch.EventPortWrapper.release(EventPortWrapper.java:233) ... 6 more The problem was observed in: java version "1.8.0_121" Solaris versions 10 and 11 But I think it also exists in 9. The problem appears to be that the Java_sun_nio_ch_SolarisEventPort_port_1dissociate function in SolarisEventPort.c is checking for ENOENT but not EBADFD. I'm not sure if the ENOENT check is needed (the associate variant does not check for it even though it's specified to be a possible return), but empirically I conclude that the EBADFD check is. -- - DML From Alan.Bateman at oracle.com Wed Jun 14 14:29:38 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Jun 2017 15:29:38 +0100 Subject: Bug in sun.nio.ch.SolarisEventPort#port_dissociate In-Reply-To: References: Message-ID: <2948b87d-e8c7-71ac-eebc-ea47bfc55992@oracle.com> On 14/06/2017 14:35, David M. Lloyd wrote: > There's a bug in sun.nio.ch.SolarisEventPort#port_dissociate which > manifests as an IOException like this: > > Exception in thread "default I/O-30" java.lang.InternalError: > java.io.IOException: File descriptor in bad state > at sun.nio.ch.EventPortWrapper.release(EventPortWrapper.java:235) > at > sun.nio.ch.EventPortSelectorImpl.implDereg(EventPortSelectorImpl.java:144) > at > sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149) > at > sun.nio.ch.EventPortSelectorImpl.doSelect(EventPortSelectorImpl.java:75) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:528) > Caused by: java.io.IOException: File descriptor in bad state > at sun.nio.ch.SolarisEventPort.port_dissociate(Native Method) > at sun.nio.ch.EventPortWrapper.release(EventPortWrapper.java:233) > ... 6 more > > The problem was observed in: > > java version "1.8.0_121" > Solaris versions 10 and 11 > > But I think it also exists in 9. The problem appears to be that the > Java_sun_nio_ch_SolarisEventPort_port_1dissociate function in > SolarisEventPort.c is checking for ENOENT but not EBADFD. I'm not > sure if the ENOENT check is needed (the associate variant does not > check for it even though it's specified to be a possible return), but > empirically I conclude that the EBADFD check is. > The timing here is a good as I think the JDK should move to using the port based Selector as the default on Solaris (it still uses the /dev/poll based Selector by default). Maybe JDK 10 is the right thing to attempt this switch. Can you say anything on when this happens? Can you distill it down to a small test case? -Alan From david.lloyd at redhat.com Wed Jun 14 14:32:51 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 14 Jun 2017 09:32:51 -0500 Subject: Bug in sun.nio.ch.SolarisEventPort#port_dissociate In-Reply-To: <2948b87d-e8c7-71ac-eebc-ea47bfc55992@oracle.com> References: <2948b87d-e8c7-71ac-eebc-ea47bfc55992@oracle.com> Message-ID: <89cd5b30-0733-727b-6723-605c4c80ae1d@redhat.com> On 06/14/2017 09:29 AM, Alan Bateman wrote: > > > On 14/06/2017 14:35, David M. Lloyd wrote: >> There's a bug in sun.nio.ch.SolarisEventPort#port_dissociate which >> manifests as an IOException like this: >> >> Exception in thread "default I/O-30" java.lang.InternalError: >> java.io.IOException: File descriptor in bad state >> at sun.nio.ch.EventPortWrapper.release(EventPortWrapper.java:235) >> at >> sun.nio.ch.EventPortSelectorImpl.implDereg(EventPortSelectorImpl.java:144) >> >> at >> sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149) >> at >> sun.nio.ch.EventPortSelectorImpl.doSelect(EventPortSelectorImpl.java:75) >> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) >> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) >> at org.xnio.nio.WorkerThread.run(WorkerThread.java:528) >> Caused by: java.io.IOException: File descriptor in bad state >> at sun.nio.ch.SolarisEventPort.port_dissociate(Native Method) >> at sun.nio.ch.EventPortWrapper.release(EventPortWrapper.java:233) >> ... 6 more >> >> The problem was observed in: >> >> java version "1.8.0_121" >> Solaris versions 10 and 11 >> >> But I think it also exists in 9. The problem appears to be that the >> Java_sun_nio_ch_SolarisEventPort_port_1dissociate function in >> SolarisEventPort.c is checking for ENOENT but not EBADFD. I'm not >> sure if the ENOENT check is needed (the associate variant does not >> check for it even though it's specified to be a possible return), but >> empirically I conclude that the EBADFD check is. >> > The timing here is a good as I think the JDK should move to using the > port based Selector as the default on Solaris (it still uses the > /dev/poll based Selector by default). Maybe JDK 10 is the right thing to > attempt this switch. > > Can you say anything on when this happens? Can you distill it down to a > small test case? It's coming from a user so my information is limited but I can establish that it is happening under load, and I think it corresponds to an open socket being abruptly closed in another thread. I am not sure whether I can get it down to a test case though. I'll see if I can get access to a Solaris system for testing. -- - DML From david.lloyd at redhat.com Thu Jun 15 13:10:00 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 15 Jun 2017 08:10:00 -0500 Subject: RFC on FileStore and /proc/mounts on Linux in a chroot jail, Docker overlayfs and with btrfs In-Reply-To: References: Message-ID: <5bc074af-c30a-4785-4ea4-3e6943f7eccb@redhat.com> Sorry for the late response on this. I asked around a bit and so far have turned up at least one possibly useful insight: /proc/self/mountinfo might be a more useful source of information than /proc[/self]/mounts. This is because mountinfo correlates the major:minor device number with the mount point/filesystem. So you can lstat a file and derive useful information by correlating the major/minor fields in mountinfo with st_dev. You could perhaps iterate all the matching filesystems looking for one which is a prefix match. The fields in mountinfo are also interesting in that they contain a unique (for at least that particular iteration of the file) ID for each mount, plus a link to the "parent" ID. More info on this file is in the proc(5) manpage. If the question is "what is the mount point", and nothing matches, then I think it's (probably?) safe to conclude that the mount point is "/". Using lstat and mountinfo, even if there is no "/" entry, you will know the de-facto mount point (which must be "/") and the device major:minor. You won't have the mount options, but maybe there are ways you can infer them. One other oddball thing I remember from my initramfs-tinkering days is that you can end up in a situation where there are multiple mounts on the same mount point. Using mountinfo also helps this case because you can use the device number to eliminate the wrong answer. The btrfs problem seems to be evidence that the assumption that there is a mount entry for every device major:minor might be flawed. If there's a device ID transition and there is no matching mountinfo entry, perhaps the best option is to simply continue traversing upwards until an existent device ID is found. Hope this helps. On 10/06/2016 07:18 PM, Brian Burkhalter wrote: > I would be interested in any ideas anyone would like to share on this topic. There are three related issues [1, 2, 3] which have been filed. The most generic issue is [3] which has been observed in three different contexts: > > A) chroot environment [1] > B) Docker container with overlay and overlay2 storage drivers [2] > C) btrfs file system with an unmounted sub-volume [2] > > In all cases the failure was the IOException with message ?Mount point not found? at line 91 in LinuxFileStore::findMountEntry [4]. This occurred because the directory identified in step 2 as the mount point of the path was not found in /proc/mounts in step 3. The mount point is either the root (/) of the path or the longest sub-path which has a different device ID from its parent. The device ID is obtained from the st_dev member of the struct stat populated by stat(2) [5]. > > In the chroot environment the contents of /proc/mounts was just > > none /proc proc rw,relatime 0 0 > > and the mount point was determined to be ?/? which is not contained in /proc/mounts so the code falls through to the IOException. > > In the overlayfs cases, when step 2 breaks out of the parent traversal loop, the device ID of the given path is valid in the operating system file system, but the device ID of the parent is not and apparently corresponds instead to a device ID in the overlayfs itself. As there is no entry in /proc/mounts for the identified mount point we get the IOException. > > In the btrfs unmounted sub-volume case, for example, a btrfs file system is mounted on /mnt and contains a sub-volume /mnt/new_subvol which is not mounted. If an attempt is made to obtain the FileStore for example corresponding to /mnt/new_subvol/junk/junk.txt, step 2 traverses upwards and breaks when it finds that the device IDs of /mnt and /mnt/new_subvol differ. As /mnt/new_subvol is not in /proc/mounts the exception ensues. > > In thinking about this I was wondering whether it could be solved by creating some ?spoofed? mount entry not in /proc/mounts. This however does not seem like an inherently great idea and would probably create problems elsewhere. > > Viewing it from a different angle, one could instead say that the chroot jail and btrfs sub-volume problems are actually due to incorrect or incomplete configurations and this is not an issue with findMountEntry() at all. The overlayfs problem could be viewed as a bug in the overlay and overlay2 storage driver implementations. This problem for example does not manifest when the aufs storage driver is used with Docker. > > Comments and suggestions welcome. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in chroot environment (*) > [2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a file in overlayfs in Docker > [3] https://bugs.openjdk.java.net/browse/JDK-8166162 - cannot get FileStore if device of path is not in /proc/mounts > [4] http://hg.openjdk.java.net/jdk9/dev/jdk/file/65042b713b12/src/java.base/linux/classes/sun/nio/fs/LinuxFileStore.java > [5] https://linux.die.net/man/2/stat > > (*) The immediate problem caused by [1] was fixed and [3] was filed to track the underlying cause. > -- - DML From amy.lu at oracle.com Fri Jun 16 02:25:23 2017 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 16 Jun 2017 10:25:23 +0800 Subject: JDK 10 RFR of JDK-8181309: Refactor shell test AsynchronousChannelProvider/custom_provider.sh to java Message-ID: <8e18e263-7b86-8bbe-a887-53a178935141@oracle.com> java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8181309 webrev: http://cr.openjdk.java.net/~amlu/8181309/webrev.00/ Thanks, Amy From amy.lu at oracle.com Fri Jun 16 05:56:30 2017 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 16 Jun 2017 13:56:30 +0800 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> Message-ID: <47383651-6d76-bace-3c12-09b317ea0bd8@oracle.com> Ping for review. (or should I withdraw this change and leave the set LC_ALL related tests as shell script tests as they are?) Thanks, Amy On 6/7/17 2:14 PM, Amy Lu wrote: > java/nio/charset/Charset/default.sh > java/nio/charset/coders/CheckSJISMappingProp.sh > java/nio/file/Path/MacPathTest.java which runs shell test: > * @run shell MacPathTest.sh > > Please review this patch to refactor these shell tests to java. > > Note that in MacPathTest.sh, it requires the test to be run with > LC_ALL=en_US.UTF-8 env. But unlike the other two tests, LC_ALL > settings here is just to setup an env in order for the test to work > correctly, it?s not the locale it intends to test. > > bug: https://bugs.openjdk.java.net/browse/JDK-8181395 > webrev: http://cr.openjdk.java.net/~amlu/8181395/webrev.00/ > > Thanks, > Amy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jun 16 08:51:51 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2017 09:51:51 +0100 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: <47383651-6d76-bace-3c12-09b317ea0bd8@oracle.com> References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> <47383651-6d76-bace-3c12-09b317ea0bd8@oracle.com> Message-ID: On 16/06/2017 06:56, Amy Lu wrote: > Ping for review. > > (or should I withdraw this change and leave the set LC_ALL related > tests as shell script tests as they are?) I think the tests would be okay if you they are run with LC_ALL set, the issue is -Dsun.jnu.encoding=UTF-8 as this was never meant to be set on the command line. There is also potential for interaction with the UTF-8 changes that Claes is working on. Hamlin has also changed a few shell tests to set several read-only properties so those will need to be re-examined too. -Alan From Alan.Bateman at oracle.com Fri Jun 16 08:53:00 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2017 09:53:00 +0100 Subject: JDK 10 RFR of JDK-8181309: Refactor shell test AsynchronousChannelProvider/custom_provider.sh to java In-Reply-To: <8e18e263-7b86-8bbe-a887-53a178935141@oracle.com> References: <8e18e263-7b86-8bbe-a887-53a178935141@oracle.com> Message-ID: <78f1c43c-f002-3b7a-e8e0-ae39c4e6a3d6@oracle.com> On 16/06/2017 03:25, Amy Lu wrote: > java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh > > Please review this patch to refactor the shell test to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8181309 > webrev: http://cr.openjdk.java.net/~amlu/8181309/webrev.00/ This looks okay to me. -Alan From amy.lu at oracle.com Fri Jun 16 10:06:58 2017 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 16 Jun 2017 18:06:58 +0800 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> <47383651-6d76-bace-3c12-09b317ea0bd8@oracle.com> Message-ID: On 6/16/17 4:51 PM, Alan Bateman wrote: > On 16/06/2017 06:56, Amy Lu wrote: >> Ping for review. >> >> (or should I withdraw this change and leave the set LC_ALL related >> tests as shell script tests as they are?) > I think the tests would be okay if you they are run with LC_ALL set, > the issue is -Dsun.jnu.encoding=UTF-8 as this was never meant to be > set on the command line. There is also potential for interaction with > the UTF-8 changes that Claes is working on. Hamlin has also changed a > few shell tests to set several read-only properties so those will need > to be re-examined too. > > -Alan Thank you Alan! I'll change MacPathTest.sh(MacPathTest.java) in a separate bug (8182376). I updated webrev, and this patch only include changes for: java/nio/charset/Charset/default.sh java/nio/charset/coders/CheckSJISMappingProp.sh Please review: http://cr.openjdk.java.net/~amlu/8181395/webrev.01/ Thanks, Amy From Alan.Bateman at oracle.com Fri Jun 16 14:06:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2017 15:06:58 +0100 Subject: JDK 10 RFR of JDK-8181395: Refactor several java/nio locale related shell tests to java In-Reply-To: References: <9d0c980b-5bf8-d47a-b0bc-d6e03bcc7731@oracle.com> <47383651-6d76-bace-3c12-09b317ea0bd8@oracle.com> Message-ID: <66325e10-9c73-4e2a-3607-565a1706d33d@oracle.com> On 16/06/2017 11:06, Amy Lu wrote: > > Thank you Alan! > > I'll change MacPathTest.sh(MacPathTest.java) in a separate bug (8182376). > > I updated webrev, and this patch only include changes for: > > java/nio/charset/Charset/default.sh > java/nio/charset/coders/CheckSJISMappingProp.sh > > Please review: > http://cr.openjdk.java.net/~amlu/8181395/webrev.01/ This looks good. -Alan From Alan.Bateman at oracle.com Fri Jun 16 15:36:00 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jun 2017 16:36:00 +0100 Subject: Bug in sun.nio.ch.SolarisEventPort#port_dissociate In-Reply-To: <89cd5b30-0733-727b-6723-605c4c80ae1d@redhat.com> References: <2948b87d-e8c7-71ac-eebc-ea47bfc55992@oracle.com> <89cd5b30-0733-727b-6723-605c4c80ae1d@redhat.com> Message-ID: On 14/06/2017 15:32, David M. Lloyd wrote: > > It's coming from a user so my information is limited but I can > establish that it is happening under load, and I think it corresponds > to an open socket being abruptly closed in another thread. > > I am not sure whether I can get it down to a test case though. I'll > see if I can get access to a Solaris system for testing. > If you get some idea on the conditions when this occurs then it would be useful. To make sure there is nothing obvious, I ran JDK tests on Solaris 11.3 system with the port Selector as the default. All the tests pass. I can't think of a scenario where port_dissociate could fail with EBADF. It is correct to ignore ENOENT as that occurs then the file descriptor registered with the port is closed by dup'ing. -Alan From david.lloyd at redhat.com Fri Jun 16 15:59:42 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 16 Jun 2017 10:59:42 -0500 Subject: Bug in sun.nio.ch.SolarisEventPort#port_dissociate In-Reply-To: References: <2948b87d-e8c7-71ac-eebc-ea47bfc55992@oracle.com> <89cd5b30-0733-727b-6723-605c4c80ae1d@redhat.com> Message-ID: <50af276f-d936-b02a-8a3b-cd5ee9b36814@redhat.com> On 06/16/2017 10:36 AM, Alan Bateman wrote: > On 14/06/2017 15:32, David M. Lloyd wrote: >> >> It's coming from a user so my information is limited but I can >> establish that it is happening under load, and I think it corresponds >> to an open socket being abruptly closed in another thread. >> >> I am not sure whether I can get it down to a test case though. I'll >> see if I can get access to a Solaris system for testing. >> > If you get some idea on the conditions when this occurs then it would be useful. To make sure there is nothing obvious, I ran JDK tests on Solaris 11.3 system with the port Selector as the default. I'll see if I can find out more. I have gained access to a test environment but I haven't been able to reproduce it in isolation either. > All the tests pass. I > can't think of a scenario where port_dissociate could fail with EBADF. It's not EBADF but EBADFD, if that makes a difference. I've been working off of various GC-related hypotheses but without knowing the exact conditions that precipitate EBADFD, I'm really shooting in the dark. One would have to examine the kernel sources to get that answer. > It is correct to ignore ENOENT as that occurs then the file descriptor > registered with the port is closed by dup'ing. Is it possible that this operation is non-atomic in the kernel, such that the descriptor is briefly in an intermediate state before being replaced by the placeholder? -- - DML From amy.lu at oracle.com Mon Jun 19 03:58:46 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 19 Jun 2017 11:58:46 +0800 Subject: JDK 10 RFR of JDK-8182421: Add @modules to java/nio/charset/coders/SJISMappingPropTest.java Message-ID: <670c740a-8510-145a-b509-d98b9998e97b@oracle.com> java/nio/charset/coders/SJISMappingPropTest.java I forgot to add module dependency when converting this test to java version. Please review the patch to add @modules jdk.charsets Thanks, Amy --- a/test/java/nio/charset/coders/SJISMappingPropTest.java +++ b/test/java/nio/charset/coders/SJISMappingPropTest.java @@ -26,6 +26,7 @@ * @bug 4879123 * @summary Verify that sun.nio.cs.map property interpreted in ja multibyte locales * @requires (os.family != "windows") + * @modules jdk.charsets * @library /test/lib * @build jdk.test.lib.Utils * jdk.test.lib.Asserts From amy.lu at oracle.com Mon Jun 19 06:09:08 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 19 Jun 2017 14:09:08 +0800 Subject: JDK 10 RFR of JDK-8181575: Refactor locale related shell test java/nio/charset/spi/basic.sh to java Message-ID: <07f21fbb-9905-3ea4-ed8e-4cc340b36c9f@oracle.com> java/nio/charset/spi/basic.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8181575 webrev: http://cr.openjdk.java.net/~amlu/8181575/webrev.00/ Thanks, Amy From Alan.Bateman at oracle.com Mon Jun 19 07:37:14 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Jun 2017 08:37:14 +0100 Subject: JDK 10 RFR of JDK-8182421: Add @modules to java/nio/charset/coders/SJISMappingPropTest.java In-Reply-To: <670c740a-8510-145a-b509-d98b9998e97b@oracle.com> References: <670c740a-8510-145a-b509-d98b9998e97b@oracle.com> Message-ID: <0159dc6f-1edf-b28c-1f60-00d967de8d88@oracle.com> On 19/06/2017 04:58, Amy Lu wrote: > java/nio/charset/coders/SJISMappingPropTest.java > > I forgot to add module dependency when converting this test to java > version. > > Please review the patch to add > > @modules jdk.charsets Looks good. From paul.sandoz at oracle.com Mon Jun 19 18:46:08 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 Jun 2017 11:46:08 -0700 Subject: JDK 10 RFR of JDK-8181575: Refactor locale related shell test java/nio/charset/spi/basic.sh to java In-Reply-To: <07f21fbb-9905-3ea4-ed8e-4cc340b36c9f@oracle.com> References: <07f21fbb-9905-3ea4-ed8e-4cc340b36c9f@oracle.com> Message-ID: Minor stuff below, no need for another round from me. Paul. CharsetProviderBasicTest ? 85 public static Iterator testCases() { 86 List cases = new ArrayList<>(); 87 Stream.of("", "ja_JP.eucJP", "tr_TR") 88 .forEach(locale -> { 89 cases.add(new Object[]{locale, List.of(""), "FOO"}); 90 cases.add(new Object[]{locale, MINIMAL_POLICY, "!FOO"}); 91 cases.add(new Object[]{locale, CP_POLICY, "FOO"}); 92 }); 93 return cases.iterator(); More for educational purposes. You can use flatMap(l -> Stream.of(?)).iterator() rather than using a list to hold the contents. 117 if (!locale.equals("")) { if (!locale.isEmpty())) { > On 18 Jun 2017, at 23:09, Amy Lu wrote: > > java/nio/charset/spi/basic.sh > > Please review this patch to refactor the shell test to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8181575 > webrev: http://cr.openjdk.java.net/~amlu/8181575/webrev.00/ > > Thanks, > Amy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From amy.lu at oracle.com Tue Jun 20 07:50:11 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 20 Jun 2017 15:50:11 +0800 Subject: JDK 10 RFR of JDK-8181575: Refactor locale related shell test java/nio/charset/spi/basic.sh to java In-Reply-To: References: <07f21fbb-9905-3ea4-ed8e-4cc340b36c9f@oracle.com> Message-ID: <945dece0-f919-eb8d-e3f1-885a11f85566@oracle.com> webrev updated, waiting for +1 http://cr.openjdk.java.net/~amlu/8181575/webrev.01/ Thanks, Amy On 6/20/17 2:46 AM, Paul Sandoz wrote: > Minor stuff below, no need for another round from me. Thank you Paul ! From amy.lu at oracle.com Tue Jun 20 07:50:39 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 20 Jun 2017 15:50:39 +0800 Subject: JDK 10 RFR of JDK-8182465: Refactor shell test java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh to java Message-ID: java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8182465 webrev: http://cr.openjdk.java.net/~amlu/8182465/webrev.00/ (run_tests.sh is a @key intermittent test due to 8038768, and the intermittent failure issue will be fixed by 8038768) Thanks, Amy From amy.lu at oracle.com Tue Jun 20 08:10:42 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 20 Jun 2017 16:10:42 +0800 Subject: JDK 10 RFR of JDK-8182376: Refactor shell test Refactor shell test java/nio/file/Path/MacPathTest.sh to java Message-ID: java/nio/file/Path/MacPathTest.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8182376 webrev: http://cr.openjdk.java.net/~amlu/8182376/webrev.00/ Thanks, Amy From Alan.Bateman at oracle.com Tue Jun 20 14:06:53 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Jun 2017 15:06:53 +0100 Subject: JDK 10 RFR of JDK-8182376: Refactor shell test Refactor shell test java/nio/file/Path/MacPathTest.sh to java In-Reply-To: References: Message-ID: <45b14626-4188-b556-7f47-1f95442483fd@oracle.com> On 20/06/2017 09:10, Amy Lu wrote: > java/nio/file/Path/MacPathTest.sh > > Please review this patch to refactor the shell test to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8182376 > webrev: http://cr.openjdk.java.net/~amlu/8182376/webrev.00/ This looks good but we will need to re-visit this to cull the excess @build lines once Igor has cleaned up and/or refactored the test library classes. -Alan From Alan.Bateman at oracle.com Tue Jun 20 14:19:04 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Jun 2017 15:19:04 +0100 Subject: JDK 10 RFR of JDK-8182465: Refactor shell test java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh to java In-Reply-To: References: Message-ID: On 20/06/2017 08:50, Amy Lu wrote: > java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh > > Please review this patch to refactor the shell test to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8182465 > webrev: http://cr.openjdk.java.net/~amlu/8182465/webrev.00/ I think it would be better to rename this to InheritedChannelTest. Otherwise looks okay although I think I would read os.name and os.arch and avoid the Platform test library class for this. -Alan. From paul.sandoz at oracle.com Tue Jun 20 17:04:10 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 20 Jun 2017 10:04:10 -0700 Subject: JDK 10 RFR of JDK-8181575: Refactor locale related shell test java/nio/charset/spi/basic.sh to java In-Reply-To: <945dece0-f919-eb8d-e3f1-885a11f85566@oracle.com> References: <07f21fbb-9905-3ea4-ed8e-4cc340b36c9f@oracle.com> <945dece0-f919-eb8d-e3f1-885a11f85566@oracle.com> Message-ID: <407CD5BD-B132-40A7-9176-8E44601A88B7@oracle.com> +1 Paul. > On 20 Jun 2017, at 00:50, Amy Lu wrote: > > webrev updated, waiting for +1 > > http://cr.openjdk.java.net/~amlu/8181575/webrev.01/ > > Thanks, > Amy > > On 6/20/17 2:46 AM, Paul Sandoz wrote: >> Minor stuff below, no need for another round from me. > Thank you Paul ! > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From david.lloyd at redhat.com Tue Jun 20 20:10:18 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 20 Jun 2017 15:10:18 -0500 Subject: RFC on FileStore and /proc/mounts on Linux in a chroot jail, Docker overlayfs and with btrfs In-Reply-To: <5bc074af-c30a-4785-4ea4-3e6943f7eccb@redhat.com> References: <5bc074af-c30a-4785-4ea4-3e6943f7eccb@redhat.com> Message-ID: <8cc2f34c-70a4-c3db-1f3d-714fe8b22e9e@redhat.com> Another fun fact. You can create a bind mount of a regular file, not just a filesystem, meaning a regular file shows up as a mount point in the various mount table files. When traversing up the filesystem tree, it might be necessary to follow bind mount links. On 06/15/2017 08:10 AM, David M. Lloyd wrote: > Sorry for the late response on this. I asked around a bit and so far > have turned up at least one possibly useful insight: > /proc/self/mountinfo might be a more useful source of information than > /proc[/self]/mounts. > > This is because mountinfo correlates the major:minor device number with > the mount point/filesystem. So you can lstat a file and derive useful > information by correlating the major/minor fields in mountinfo with > st_dev. You could perhaps iterate all the matching filesystems looking > for one which is a prefix match. > > The fields in mountinfo are also interesting in that they contain a > unique (for at least that particular iteration of the file) ID for each > mount, plus a link to the "parent" ID. More info on this file is in the > proc(5) manpage. > > If the question is "what is the mount point", and nothing matches, then > I think it's (probably?) safe to conclude that the mount point is "/". > Using lstat and mountinfo, even if there is no "/" entry, you will know > the de-facto mount point (which must be "/") and the device major:minor. > You won't have the mount options, but maybe there are ways you can > infer them. > > One other oddball thing I remember from my initramfs-tinkering days is > that you can end up in a situation where there are multiple mounts on > the same mount point. Using mountinfo also helps this case because you > can use the device number to eliminate the wrong answer. > > The btrfs problem seems to be evidence that the assumption that there is > a mount entry for every device major:minor might be flawed. If there's > a device ID transition and there is no matching mountinfo entry, perhaps > the best option is to simply continue traversing upwards until an > existent device ID is found. > > Hope this helps. > > On 10/06/2016 07:18 PM, Brian Burkhalter wrote: >> I would be interested in any ideas anyone would like to share on this >> topic. There are three related issues [1, 2, 3] which have been filed. >> The most generic issue is [3] which has been observed in three >> different contexts: >> >> A) chroot environment [1] >> B) Docker container with overlay and overlay2 storage drivers [2] >> C) btrfs file system with an unmounted sub-volume [2] >> >> In all cases the failure was the IOException with message ?Mount point >> not found? at line 91 in LinuxFileStore::findMountEntry [4]. This >> occurred because the directory identified in step 2 as the mount point >> of the path was not found in /proc/mounts in step 3. The mount point >> is either the root (/) of the path or the longest sub-path which has a >> different device ID from its parent. The device ID is obtained from >> the st_dev member of the struct stat populated by stat(2) [5]. >> >> In the chroot environment the contents of /proc/mounts was just >> >> none /proc proc rw,relatime 0 0 >> >> and the mount point was determined to be ?/? which is not contained in >> /proc/mounts so the code falls through to the IOException. >> >> In the overlayfs cases, when step 2 breaks out of the parent traversal >> loop, the device ID of the given path is valid in the operating system >> file system, but the device ID of the parent is not and apparently >> corresponds instead to a device ID in the overlayfs itself. As there >> is no entry in /proc/mounts for the identified mount point we get the >> IOException. >> >> In the btrfs unmounted sub-volume case, for example, a btrfs file >> system is mounted on /mnt and contains a sub-volume /mnt/new_subvol >> which is not mounted. If an attempt is made to obtain the FileStore >> for example corresponding to /mnt/new_subvol/junk/junk.txt, step 2 >> traverses upwards and breaks when it finds that the device IDs of /mnt >> and /mnt/new_subvol differ. As /mnt/new_subvol is not in /proc/mounts >> the exception ensues. >> >> In thinking about this I was wondering whether it could be solved by >> creating some ?spoofed? mount entry not in /proc/mounts. This however >> does not seem like an inherently great idea and would probably create >> problems elsewhere. >> >> Viewing it from a different angle, one could instead say that the >> chroot jail and btrfs sub-volume problems are actually due to >> incorrect or incomplete configurations and this is not an issue with >> findMountEntry() at all. The overlayfs problem could be viewed as a >> bug in the overlay and overlay2 storage driver implementations. This >> problem for example does not manifest when the aufs storage driver is >> used with Docker. >> >> Comments and suggestions welcome. >> >> Thanks, >> >> Brian >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get >> FileStore in chroot environment (*) >> [2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get >> FileStore for a file in overlayfs in Docker >> [3] https://bugs.openjdk.java.net/browse/JDK-8166162 - cannot get >> FileStore if device of path is not in /proc/mounts >> [4] >> http://hg.openjdk.java.net/jdk9/dev/jdk/file/65042b713b12/src/java.base/linux/classes/sun/nio/fs/LinuxFileStore.java >> >> [5] https://linux.die.net/man/2/stat >> >> (*) The immediate problem caused by [1] was fixed and [3] was filed to >> track the underlying cause. >> > > -- - DML From amy.lu at oracle.com Wed Jun 21 07:16:01 2017 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 21 Jun 2017 15:16:01 +0800 Subject: JDK 10 RFR of JDK-8182465: Refactor shell test java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh to java In-Reply-To: References: Message-ID: On 6/20/17 10:19 PM, Alan Bateman wrote: > On 20/06/2017 08:50, Amy Lu wrote: >> java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh >> >> Please review this patch to refactor the shell test to java. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8182465 >> webrev: http://cr.openjdk.java.net/~amlu/8182465/webrev.00/ > I think it would be better to rename this to InheritedChannelTest. > > Otherwise looks okay although I think I would read os.name and os.arch > and avoid the Platform test library class for this. > > -Alan. Thank you Alan! Pushed with suggested changes. Thanks, Amy From christoph.langer at sap.com Tue Jun 27 06:50:24 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 27 Jun 2017 06:50:24 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: Message-ID: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> Hi Ogata, I'm redirecting this RFR to core-libs-dev and nio-dev as it potentially affects all platforms and should be discussed there. As for your proposal: I can generally understand that using volatile at this place hurts performance on the power platform and this should be improved. I however don't fully oversee if just removing the volatile qualifier is the only thing to do here. Maybe one should implement some double checked locking pattern around the static field bugLevel and its initialization from system properties? I guess during VM initialization multiple threads can got to this place and the volatile qualifier was added for synchronizing access to "bugLevel". So, waiting for comments from other experts... Best regards Christoph > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Kazunori Ogata > Sent: Dienstag, 27. Juni 2017 07:13 > To: jdk10-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: RFR: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi all, please review a change for JDK-8182743. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8182743 > Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > This change removes a "volatile" qualifier of a static variable used by > Charset.atBugLevel() because it does not improve thread-safety of the code > and it hurts performance on PPC (and should be the same in ARM, too). > Removing the "volatile" improved performance by 26% in a POWER8 machine > using following micro benchmark: > > ------ > import java.io.*; > import java.nio.ByteBuffer; > import java.nio.charset.Charset; > import java.util.ArrayList; > > class ConvertTest { > static String str; > > public static void main(String[] args) { > byte buf[] = { 0x41 }; > Charset fromCharset = Charset.forName("iso-8859-1"); > > long start = System.currentTimeMillis(); > > for(long i = 0; i < 100000000; i++) > str = new String(buf, 0, 1, fromCharset); > > long end = System.currentTimeMillis(); > > System.out.println("Elapsed: "+(end-start)+" ms"); > } > } > ------ > > > Regards, > Ogata From Alan.Bateman at oracle.com Tue Jun 27 07:01:25 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Jun 2017 08:01:25 +0100 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> Message-ID: <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> On 27/06/2017 07:50, Langer, Christoph wrote: > Hi Ogata, > > I'm redirecting this RFR to core-libs-dev and nio-dev as it potentially affects all platforms and should be discussed there. > > As for your proposal: I can generally understand that using volatile at this place hurts performance on the power platform and this should be improved. I however don't fully oversee if just removing the volatile qualifier is the only thing to do here. Maybe one should implement some double checked locking pattern around the static field bugLevel and its initialization from system properties? I guess during VM initialization multiple threads can got to this place and the volatile qualifier was added for synchronizing access to "bugLevel". > It could be changed to be a final field in a holder class. It might be better if we can just remove the test from Charset.checkName as I think that dates back to an incompatible change going from JDK 1.4 to JDK 5 that should no longer be a concern. -Alan From claes.redestad at oracle.com Tue Jun 27 07:36:20 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 27 Jun 2017 09:36:20 +0200 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> Message-ID: On 2017-06-27 09:01, Alan Bateman wrote: > It might be better if we can just remove the test from > Charset.checkName as I think that dates back to an incompatible change > going from JDK 1.4 to JDK 5 that should no longer be a concern. The check of Charset.atBugLevel in checkName should no longer happen for the majority of situations, as that test is now only done if the charset name is "" (see https://bugs.openjdk.java.net/browse/JDK-8174831), since what differs between 1.4 and 1.5 was apparently whether or not the empty string was to be accepted as a valid Charset... So yes, if we can get rid of the test altogether, we'll be even better off! /Claes From Alan.Bateman at oracle.com Tue Jun 27 08:13:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Jun 2017 09:13:19 +0100 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> Message-ID: <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> On 27/06/2017 08:36, Claes Redestad wrote: > > The check of Charset.atBugLevel in checkName should no longer happen > for the majority of situations, as that test is now only done if the > charset name is "" (see > https://bugs.openjdk.java.net/browse/JDK-8174831), Kazunori's mail didn't mention the JDK build he is using, it may have been JDK 8 rather than JDK 9. > since what differs between 1.4 and 1.5 was apparently whether or not > the empty string was to be accepted as a valid Charset... > > So yes, if we can get rid of the test altogether, we'll be even better > off! JDK-4786884 is the original issue. If there was any code dependent on the broken behavior in 1.4 then I would expect it should have been fixed by now. So I think it can be removed. -Alan From OGATAK at jp.ibm.com Tue Jun 27 08:31:21 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 27 Jun 2017 17:31:21 +0900 Subject: Fw: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() Message-ID: Hi, I'm re-posting this mail because I sent the old one before I subscribe core-libs-dev and nio-dev. Sorry if you receive this mail twice. Regards, Ogata ----- Forwarded by Kazunori Ogata/Japan/IBM on 2017/06/27 17:28 ----- "ppc-aix-port-dev" wrote on 2017/06/27 17:12:45: > From: "Kazunori Ogata" > To: Aleksey Shipilev > Cc: core-libs-dev , "nio- > dev at openjdk.java.net" , "ppc-aix-port- > dev at openjdk.java.net" > Date: 2017/06/27 17:13 > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > Sent by: "ppc-aix-port-dev" > > Hi Christoph, > > Thank you for redirecting this request to appropriate mailing lists. > > > Hi Aleksey, > > Thank you for reviewing the patch. > > > Regards, > Ogata > > > Aleksey Shipilev wrote on 2017/06/27 15:58:56: > > > From: Aleksey Shipilev > > To: "Langer, Christoph" , Kazunori Ogata > > , core-libs-dev , > "nio- > > dev at openjdk.java.net" > > Cc: "ppc-aix-port-dev at openjdk.java.net" > > > Date: 2017/06/27 15:59 > > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > On 06/27/2017 08:50 AM, Langer, Christoph wrote: > > > So, waiting for comments from other experts... > > > > >> Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > > > This patch is fine as stated. > > > > Without volatile, there is a benign data race on the bugLevel field, > which is > > okay, assuming "sun.nio.cs.bugLevel" never actually changes. Doing > > double-checked-locking seems excessive here, because we can accept more > than one > > invocation of privilegedGetProperty. > > > > -Aleksey > > > > > > > > > > [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] > From OGATAK at jp.ibm.com Tue Jun 27 08:34:46 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 27 Jun 2017 17:34:46 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> Message-ID: Alan Bateman wrote on 2017/06/27 16:01:25: > From: Alan Bateman > To: "Langer, Christoph" , Kazunori Ogata > , core-libs-dev , "nio- > dev at openjdk.java.net" > Cc: "ppc-aix-port-dev at openjdk.java.net" > Date: 2017/06/27 16:01 > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > On 27/06/2017 07:50, Langer, Christoph wrote: > > Hi Ogata, > > > > I'm redirecting this RFR to core-libs-dev and nio-dev as it potentially > affects all platforms and should be discussed there. > > > > As for your proposal: I can generally understand that using volatile at > this place hurts performance on the power platform and this should be > improved. I however don't fully oversee if just removing the volatile > qualifier is the only thing to do here. Maybe one should implement some > double checked locking pattern around the static field bugLevel and its > initialization from system properties? I guess during VM initialization > multiple threads can got to this place and the volatile qualifier was > added for synchronizing access to "bugLevel". > > > It could be changed to be a final field in a holder class. The code looks that it doesn't use final intentionally because it postpones setting set bugLevel until VM.isBooted() returns true, though I'm not sure if the value of privilegedGetProperty() can change during a bootstrap of JVM. ----- 289: if (!VM.isBooted()) 290: return false; ----- > It might be > better if we can just remove the test from Charset.checkName as I think > that dates back to an incompatible change going from JDK 1.4 to JDK 5 > that should no longer be a concern. > > -Alan > From OGATAK at jp.ibm.com Tue Jun 27 08:39:10 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 27 Jun 2017 17:39:10 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> Message-ID: Hi Alan, I'm working on the JDK 10 source code, but I verified JDK 8 has the same code w.r.t. use of volatile. Regards, Ogata Alan Bateman wrote on 2017/06/27 17:13:19: > From: Alan Bateman > To: Claes Redestad , "Langer, Christoph" > , Kazunori Ogata , core-libs- > dev , "nio-dev at openjdk.java.net" dev at openjdk.java.net> > Cc: "ppc-aix-port-dev at openjdk.java.net" > Date: 2017/06/27 17:13 > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > On 27/06/2017 08:36, Claes Redestad wrote: > > > > The check of Charset.atBugLevel in checkName should no longer happen > > for the majority of situations, as that test is now only done if the > > charset name is "" (see > > https://bugs.openjdk.java.net/browse/JDK-8174831), > Kazunori's mail didn't mention the JDK build he is using, it may have > been JDK 8 rather than JDK 9. > > > since what differs between 1.4 and 1.5 was apparently whether or not > > the empty string was to be accepted as a valid Charset... > > > > So yes, if we can get rid of the test altogether, we'll be even better > > off! > JDK-4786884 is the original issue. If there was any code dependent on > the broken behavior in 1.4 then I would expect it should have been fixed > by now. So I think it can be removed. > > -Alan > From sean.coffey at oracle.com Tue Jun 27 08:40:06 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 27 Jun 2017 09:40:06 +0100 Subject: RFR: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: Message-ID: This should be reviewed on nio-dev. Please drop jdk10-dev on reply. The atBugLevel(String) method seems to be more for legacy use from JDK 1.4/1.5 family. Maybe it's time to drop its use? We'd need to check if the VM.isBooted() call is still necessary. regards, Sean. On 27/06/2017 06:12, Kazunori Ogata wrote: > Hi all, please review a change for JDK-8182743. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8182743 > Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > This change removes a "volatile" qualifier of a static variable used by > Charset.atBugLevel() because it does not improve thread-safety of the code > and it hurts performance on PPC (and should be the same in ARM, too). > Removing the "volatile" improved performance by 26% in a POWER8 machine > using following micro benchmark: > > ------ > import java.io.*; > import java.nio.ByteBuffer; > import java.nio.charset.Charset; > import java.util.ArrayList; > > class ConvertTest { > static String str; > > public static void main(String[] args) { > byte buf[] = { 0x41 }; > Charset fromCharset = Charset.forName("iso-8859-1"); > > long start = System.currentTimeMillis(); > > for(long i = 0; i < 100000000; i++) > str = new String(buf, 0, 1, fromCharset); > > long end = System.currentTimeMillis(); > > System.out.println("Elapsed: "+(end-start)+" ms"); > } > } > ------ > > > Regards, > Ogata > From OGATAK at jp.ibm.com Tue Jun 27 08:48:54 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 27 Jun 2017 17:48:54 +0900 Subject: RFR: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: Message-ID: Hi Sean, Thank you for your suggestion. Langer, Christoph has gave me the same comment and redirected the RFR to core-libs-dev and nio-dev. Sorry for not telling it here jdk10-dev earlier. Regards, Ogata Se?n Coffey wrote on 2017/06/27 17:40:06: > From: Se?n Coffey > To: Kazunori Ogata , ppc-aix-port-dev at openjdk.java.net, > nio-dev at openjdk.java.net > Cc: jdk10-dev at openjdk.java.net > Date: 2017/06/27 17:40 > Subject: Re: RFR: 8179527: Ineffective use of volatile hurts performance > of Charset.atBugLevel() > > This should be reviewed on nio-dev. Please drop jdk10-dev on reply. > > The atBugLevel(String) method seems to be more for legacy use from JDK > 1.4/1.5 family. Maybe it's time to drop its use? We'd need to check if > the VM.isBooted() call is still necessary. > > regards, > Sean. > > On 27/06/2017 06:12, Kazunori Ogata wrote: > > Hi all, please review a change for JDK-8182743. > > > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8182743 > > Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > > > This change removes a "volatile" qualifier of a static variable used by > > Charset.atBugLevel() because it does not improve thread-safety of the code > > and it hurts performance on PPC (and should be the same in ARM, too). > > Removing the "volatile" improved performance by 26% in a POWER8 machine > > using following micro benchmark: > > > > ------ > > import java.io.*; > > import java.nio.ByteBuffer; > > import java.nio.charset.Charset; > > import java.util.ArrayList; > > > > class ConvertTest { > > static String str; > > > > public static void main(String[] args) { > > byte buf[] = { 0x41 }; > > Charset fromCharset = Charset.forName("iso-8859-1"); > > > > long start = System.currentTimeMillis(); > > > > for(long i = 0; i < 100000000; i++) > > str = new String(buf, 0, 1, fromCharset); > > > > long end = System.currentTimeMillis(); > > > > System.out.println("Elapsed: "+(end-start)+" ms"); > > } > > } > > ------ > > > > > > Regards, > > Ogata > > > From Alan.Bateman at oracle.com Tue Jun 27 11:25:18 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Jun 2017 12:25:18 +0100 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> Message-ID: <28ef06c9-c89c-02f4-58e1-3f47a705101b@oracle.com> On 27/06/2017 09:34, Kazunori Ogata wrote: > : > The code looks that it doesn't use final intentionally because it > postpones setting set bugLevel until VM.isBooted() returns true, though > I'm not sure if the value of privilegedGetProperty() can change during a > bootstrap of JVM. > ----- > 289: if (!VM.isBooted()) > 290: return false; > ----- > I think we can remove the atBugLevel check from Charset.checkName and also the CharsetEncoder/CharsetDecoder constructors. -Alan From christoph.langer at sap.com Tue Jun 27 18:32:51 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 27 Jun 2017 18:32:51 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> Message-ID: <9a235816b1544dd587a1e6d2268e6407@sap.com> Hi Ogata, I think I agree with Alan that the Charset.atBugLevel() method can completely be eliminated from java/nio/charset. Ogata, would you respin your change to remove it and post it for review? I can then sponsor it for you. @Alan: Do we need a CSR ("Compatibility & Specification Review") request here since support for "sun.nio.cs.bugLevel" will be removed? Best regards Christoph > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Dienstag, 27. Juni 2017 10:13 > To: Claes Redestad ; Langer, Christoph > ; Kazunori Ogata ; > core-libs-dev ; nio-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > On 27/06/2017 08:36, Claes Redestad wrote: > > > > The check of Charset.atBugLevel in checkName should no longer happen > > for the majority of situations, as that test is now only done if the > > charset name is "" (see > > https://bugs.openjdk.java.net/browse/JDK-8174831), > Kazunori's mail didn't mention the JDK build he is using, it may have > been JDK 8 rather than JDK 9. > > > since what differs between 1.4 and 1.5 was apparently whether or not > > the empty string was to be accepted as a valid Charset... > > > > So yes, if we can get rid of the test altogether, we'll be even better > > off! > JDK-4786884 is the original issue. If there was any code dependent on > the broken behavior in 1.4 then I would expect it should have been fixed > by now. So I think it can be removed. > > -Alan From shade at redhat.com Tue Jun 27 06:58:56 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Jun 2017 08:58:56 +0200 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> Message-ID: On 06/27/2017 08:50 AM, Langer, Christoph wrote: > So, waiting for comments from other experts... >> Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ This patch is fine as stated. Without volatile, there is a benign data race on the bugLevel field, which is okay, assuming "sun.nio.cs.bugLevel" never actually changes. Doing double-checked-locking seems excessive here, because we can accept more than one invocation of privilegedGetProperty. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From OGATAK at jp.ibm.com Wed Jun 28 06:20:53 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 28 Jun 2017 15:20:53 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <9a235816b1544dd587a1e6d2268e6407@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> Message-ID: Hi Christoph, Thank you for your suggestions and offering to sponsor my changes. Here is the updated webrev that removes the atBugLevel() definition in Charset.java and its call sites in Charset.java and Charset-X-Coder.java.template. Please review this: http://cr.openjdk.java.net/~horii/8179527/webrev.01/ Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 03:32:51: > From: "Langer, Christoph" > To: Alan Bateman , Kazunori Ogata > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, Claes Redestad , core- > libs-dev , "nio-dev at openjdk.java.net" > > Date: 2017/06/28 03:32 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Ogata, > > I think I agree with Alan that the Charset.atBugLevel() method can > completely be eliminated from java/nio/charset. > > Ogata, would you respin your change to remove it and post it for review? I > can then sponsor it for you. > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > here since support for "sun.nio.cs.bugLevel" will be removed? > > Best regards > Christoph > > > -----Original Message----- > > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > > Sent: Dienstag, 27. Juni 2017 10:13 > > To: Claes Redestad ; Langer, Christoph > > ; Kazunori Ogata ; > > core-libs-dev ; nio-dev at openjdk.java.net > > Cc: ppc-aix-port-dev at openjdk.java.net > > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > On 27/06/2017 08:36, Claes Redestad wrote: > > > > > > The check of Charset.atBugLevel in checkName should no longer happen > > > for the majority of situations, as that test is now only done if the > > > charset name is "" (see > > > https://bugs.openjdk.java.net/browse/JDK-8174831), > > Kazunori's mail didn't mention the JDK build he is using, it may have > > been JDK 8 rather than JDK 9. > > > > > since what differs between 1.4 and 1.5 was apparently whether or not > > > the empty string was to be accepted as a valid Charset... > > > > > > So yes, if we can get rid of the test altogether, we'll be even better > > > off! > > JDK-4786884 is the original issue. If there was any code dependent on > > the broken behavior in 1.4 then I would expect it should have been fixed > > by now. So I think it can be removed. > > > > -Alan From christoph.langer at sap.com Wed Jun 28 06:45:41 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Jun 2017 06:45:41 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> Message-ID: <587313ab0dcf483abb3eb300bc779695@sap.com> Hi Ogata, this looks fine. The copyright year in Charset-X-Coder.java.template needs to be updated, but I can do that when I push it. Waiting for another review... Best regards Christoph > -----Original Message----- > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > Sent: Mittwoch, 28. Juni 2017 08:21 > To: Langer, Christoph > Cc: Alan Bateman ; Claes Redestad > ; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Christoph, > > Thank you for your suggestions and offering to sponsor my changes. > > Here is the updated webrev that removes the atBugLevel() definition in > Charset.java and its call sites in Charset.java and > Charset-X-Coder.java.template. Please review this: > > http://cr.openjdk.java.net/~horii/8179527/webrev.01/ > > > Regards, > Ogata > > > "Langer, Christoph" wrote on 2017/06/28 > 03:32:51: > > > From: "Langer, Christoph" > > To: Alan Bateman , Kazunori Ogata > > > Cc: "ppc-aix-port-dev at openjdk.java.net" > dev at openjdk.java.net>, Claes Redestad , > core- > > libs-dev , "nio-dev at openjdk.java.net" > > > > Date: 2017/06/28 03:32 > > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > Hi Ogata, > > > > I think I agree with Alan that the Charset.atBugLevel() method can > > completely be eliminated from java/nio/charset. > > > > Ogata, would you respin your change to remove it and post it for review? > I > > can then sponsor it for you. > > > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > > > here since support for "sun.nio.cs.bugLevel" will be removed? > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > > > Sent: Dienstag, 27. Juni 2017 10:13 > > > To: Claes Redestad ; Langer, Christoph > > > ; Kazunori Ogata ; > > > core-libs-dev ; > nio-dev at openjdk.java.net > > > Cc: ppc-aix-port-dev at openjdk.java.net > > > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > > > Charset.atBugLevel() > > > > > > On 27/06/2017 08:36, Claes Redestad wrote: > > > > > > > > The check of Charset.atBugLevel in checkName should no longer > happen > > > > for the majority of situations, as that test is now only done if the > > > > charset name is "" (see > > > > https://bugs.openjdk.java.net/browse/JDK-8174831), > > > Kazunori's mail didn't mention the JDK build he is using, it may have > > > been JDK 8 rather than JDK 9. > > > > > > > since what differs between 1.4 and 1.5 was apparently whether or not > > > > the empty string was to be accepted as a valid Charset... > > > > > > > > So yes, if we can get rid of the test altogether, we'll be even > better > > > > off! > > > JDK-4786884 is the original issue. If there was any code dependent on > > > the broken behavior in 1.4 then I would expect it should have been > fixed > > > by now. So I think it can be removed. > > > > > > -Alan > From OGATAK at jp.ibm.com Wed Jun 28 06:50:45 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 28 Jun 2017 15:50:45 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <587313ab0dcf483abb3eb300bc779695@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <587313ab0dcf483abb3eb300bc779695@sap.com> Message-ID: Thank you, Christoph. Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 15:45:41: > From: "Langer, Christoph" > To: Kazunori Ogata > Cc: Alan Bateman , Claes Redestad > , core-libs-dev dev at openjdk.java.net>, "nio-dev at openjdk.java.net" dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net> > Date: 2017/06/28 15:45 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Ogata, > > this looks fine. > > The copyright year in Charset-X-Coder.java.template needs to be updated, > but I can do that when I push it. > > Waiting for another review... > > Best regards > Christoph > > > -----Original Message----- > > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > > Sent: Mittwoch, 28. Juni 2017 08:21 > > To: Langer, Christoph > > Cc: Alan Bateman ; Claes Redestad > > ; core-libs-dev > dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > > dev at openjdk.java.net > > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > Hi Christoph, > > > > Thank you for your suggestions and offering to sponsor my changes. > > > > Here is the updated webrev that removes the atBugLevel() definition in > > Charset.java and its call sites in Charset.java and > > Charset-X-Coder.java.template. Please review this: > > > > http://cr.openjdk.java.net/~horii/8179527/webrev.01/ > > > > > > Regards, > > Ogata > > > > > > "Langer, Christoph" wrote on 2017/06/28 > > 03:32:51: > > > > > From: "Langer, Christoph" > > > To: Alan Bateman , Kazunori Ogata > > > > > Cc: "ppc-aix-port-dev at openjdk.java.net" > > dev at openjdk.java.net>, Claes Redestad , > > core- > > > libs-dev , "nio-dev at openjdk.java.net" > > > > > > Date: 2017/06/28 03:32 > > > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > > > Charset.atBugLevel() > > > > > > Hi Ogata, > > > > > > I think I agree with Alan that the Charset.atBugLevel() method can > > > completely be eliminated from java/nio/charset. > > > > > > Ogata, would you respin your change to remove it and post it for review? > > I > > > can then sponsor it for you. > > > > > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > > > > > here since support for "sun.nio.cs.bugLevel" will be removed? > > > > > > Best regards > > > Christoph > > > > > > > -----Original Message----- > > > > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > > > > Sent: Dienstag, 27. Juni 2017 10:13 > > > > To: Claes Redestad ; Langer, Christoph > > > > ; Kazunori Ogata ; > > > > core-libs-dev ; > > nio-dev at openjdk.java.net > > > > Cc: ppc-aix-port-dev at openjdk.java.net > > > > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > > > > Charset.atBugLevel() > > > > > > > > On 27/06/2017 08:36, Claes Redestad wrote: > > > > > > > > > > The check of Charset.atBugLevel in checkName should no longer > > happen > > > > > for the majority of situations, as that test is now only done if the > > > > > charset name is "" (see > > > > > https://bugs.openjdk.java.net/browse/JDK-8174831), > > > > Kazunori's mail didn't mention the JDK build he is using, it may have > > > > been JDK 8 rather than JDK 9. > > > > > > > > > since what differs between 1.4 and 1.5 was apparently whether or not > > > > > the empty string was to be accepted as a valid Charset... > > > > > > > > > > So yes, if we can get rid of the test altogether, we'll be even > > better > > > > > off! > > > > JDK-4786884 is the original issue. If there was any code dependent on > > > > the broken behavior in 1.4 then I would expect it should have been > > fixed > > > > by now. So I think it can be removed. > > > > > > > > -Alan > > > From peter.levart at gmail.com Wed Jun 28 08:44:38 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 28 Jun 2017 10:44:38 +0200 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> Message-ID: Hi Ogata, The change looks good. But I think this needs to go through CSR. The CSR FAQ page at: https://wiki.openjdk.java.net/display/csr/CSR+FAQs writes... Q: What sort of changes require CSR review? A: Any change to a JDK interface meant to be used outside of the JDK itself requires CSR review. In this context "interface" isn't limited to the Java programing language definition of an interface, but encompasses the broader concept of a protocol between the JDK and users of the JDK. Examples of interfaces by this definition include: ... * Changing or defining a new system or security property* The FAQ also writes: Q: How do I create a CSR ? A: Do not directly create a CSR from the Create Menu. JIRA will let you do this right up until the moment you try to save it and find your typing was in vain. Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports. Since Christoph has already volunteered to be your sponsor, you could ask him to file the CSR for you. Or I can volunteer to file it (and learn how this goes) if Christoph doesn't have the time. It's Christophs call... Regards, Peter On 06/28/2017 08:20 AM, Kazunori Ogata wrote: > Hi Christoph, > > Thank you for your suggestions and offering to sponsor my changes. > > Here is the updated webrev that removes the atBugLevel() definition in > Charset.java and its call sites in Charset.java and > Charset-X-Coder.java.template. Please review this: > > http://cr.openjdk.java.net/~horii/8179527/webrev.01/ > > > Regards, > Ogata > > > "Langer, Christoph" wrote on 2017/06/28 > 03:32:51: > >> From: "Langer, Christoph" >> To: Alan Bateman , Kazunori Ogata > >> Cc: "ppc-aix-port-dev at openjdk.java.net" > dev at openjdk.java.net>, Claes Redestad , core- >> libs-dev , "nio-dev at openjdk.java.net" >> >> Date: 2017/06/28 03:32 >> Subject: RE: 8179527: Ineffective use of volatile hurts performance of >> Charset.atBugLevel() >> >> Hi Ogata, >> >> I think I agree with Alan that the Charset.atBugLevel() method can >> completely be eliminated from java/nio/charset. >> >> Ogata, would you respin your change to remove it and post it for review? > I >> can then sponsor it for you. >> >> @Alan: Do we need a CSR ("Compatibility & Specification Review") request >> here since support for "sun.nio.cs.bugLevel" will be removed? >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>> Sent: Dienstag, 27. Juni 2017 10:13 >>> To: Claes Redestad ; Langer, Christoph >>> ; Kazunori Ogata ; >>> core-libs-dev ; > nio-dev at openjdk.java.net >>> Cc: ppc-aix-port-dev at openjdk.java.net >>> Subject: Re: 8179527: Ineffective use of volatile hurts performance of >>> Charset.atBugLevel() >>> >>> On 27/06/2017 08:36, Claes Redestad wrote: >>>> The check of Charset.atBugLevel in checkName should no longer happen >>>> for the majority of situations, as that test is now only done if the >>>> charset name is "" (see >>>> https://bugs.openjdk.java.net/browse/JDK-8174831), >>> Kazunori's mail didn't mention the JDK build he is using, it may have >>> been JDK 8 rather than JDK 9. >>> >>>> since what differs between 1.4 and 1.5 was apparently whether or not >>>> the empty string was to be accepted as a valid Charset... >>>> >>>> So yes, if we can get rid of the test altogether, we'll be even > better >>>> off! >>> JDK-4786884 is the original issue. If there was any code dependent on >>> the broken behavior in 1.4 then I would expect it should have been > fixed >>> by now. So I think it can be removed. >>> >>> -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Jun 28 08:47:41 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Jun 2017 08:47:41 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> Message-ID: <38ffe8c4e4b44dd9994d743f17985667@sap.com> Hi Petar, thanks for pointing out the need for the CSR, I thought so too. I?ll run through the CSR process? It?ll probably be an interesting learning experience for me as well ? Best regards Christoph From: Peter Levart [mailto:peter.levart at gmail.com] Sent: Mittwoch, 28. Juni 2017 10:45 To: Kazunori Ogata ; Langer, Christoph Cc: ppc-aix-port-dev at openjdk.java.net; core-libs-dev ; nio-dev at openjdk.java.net Subject: Re: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() Hi Ogata, The change looks good. But I think this needs to go through CSR. The CSR FAQ page at: https://wiki.openjdk.java.net/display/csr/CSR+FAQs writes... Q: What sort of changes require CSR review? A: Any change to a JDK interface meant to be used outside of the JDK itself requires CSR review. In this context "interface" isn't limited to the Java programing language definition of an interface, but encompasses the broader concept of a protocol between the JDK and users of the JDK. Examples of interfaces by this definition include: ... Changing or defining a new system or security property The FAQ also writes: Q: How do I create a CSR ? A: Do not directly create a CSR from the Create Menu. JIRA will let you do this right up until the moment you try to save it and find your typing was in vain. Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports. Since Christoph has already volunteered to be your sponsor, you could ask him to file the CSR for you. Or I can volunteer to file it (and learn how this goes) if Christoph doesn't have the time. It's Christophs call... Regards, Peter On 06/28/2017 08:20 AM, Kazunori Ogata wrote: Hi Christoph, Thank you for your suggestions and offering to sponsor my changes. Here is the updated webrev that removes the atBugLevel() definition in Charset.java and its call sites in Charset.java and Charset-X-Coder.java.template. Please review this: http://cr.openjdk.java.net/~horii/8179527/webrev.01/ Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 03:32:51: From: "Langer, Christoph" To: Alan Bateman , Kazunori Ogata Cc: "ppc-aix-port-dev at openjdk.java.net" >, Claes Redestad , core- libs-dev , "nio-dev at openjdk.java.net" Date: 2017/06/28 03:32 Subject: RE: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() Hi Ogata, I think I agree with Alan that the Charset.atBugLevel() method can completely be eliminated from java/nio/charset. Ogata, would you respin your change to remove it and post it for review? I can then sponsor it for you. @Alan: Do we need a CSR ("Compatibility & Specification Review") request here since support for "sun.nio.cs.bugLevel" will be removed? Best regards Christoph -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Dienstag, 27. Juni 2017 10:13 To: Claes Redestad ; Langer, Christoph ; Kazunori Ogata ; core-libs-dev ; nio-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() On 27/06/2017 08:36, Claes Redestad wrote: The check of Charset.atBugLevel in checkName should no longer happen for the majority of situations, as that test is now only done if the charset name is "" (see https://bugs.openjdk.java.net/browse/JDK-8174831), Kazunori's mail didn't mention the JDK build he is using, it may have been JDK 8 rather than JDK 9. since what differs between 1.4 and 1.5 was apparently whether or not the empty string was to be accepted as a valid Charset... So yes, if we can get rid of the test altogether, we'll be even better off! JDK-4786884 is the original issue. If there was any code dependent on the broken behavior in 1.4 then I would expect it should have been fixed by now. So I think it can be removed. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Wed Jun 28 08:57:57 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Jun 2017 10:57:57 +0200 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <587313ab0dcf483abb3eb300bc779695@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <587313ab0dcf483abb3eb300bc779695@sap.com> Message-ID: Looks good to me, pending CSR approval. Additionally, maybe this is a good opportunity to re-examine the very similarly implemented sun.nio.ch.bugLevel used in sun.nio.ch.Util and sun.nio.ch.SelectorImpl? As a separate bug, of course. /Claes On 2017-06-28 08:45, Langer, Christoph wrote: > Hi Ogata, > > this looks fine. > > The copyright year in Charset-X-Coder.java.template needs to be updated, but I can do that when I push it. > > Waiting for another review... > > Best regards > Christoph > >> -----Original Message----- >> From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] >> Sent: Mittwoch, 28. Juni 2017 08:21 >> To: Langer, Christoph >> Cc: Alan Bateman ; Claes Redestad >> ; core-libs-dev > dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- >> dev at openjdk.java.net >> Subject: RE: 8179527: Ineffective use of volatile hurts performance of >> Charset.atBugLevel() >> >> Hi Christoph, >> >> Thank you for your suggestions and offering to sponsor my changes. >> >> Here is the updated webrev that removes the atBugLevel() definition in >> Charset.java and its call sites in Charset.java and >> Charset-X-Coder.java.template. Please review this: >> >> http://cr.openjdk.java.net/~horii/8179527/webrev.01/ >> >> >> Regards, >> Ogata >> >> >> "Langer, Christoph" wrote on 2017/06/28 >> 03:32:51: >> >>> From: "Langer, Christoph" >>> To: Alan Bateman , Kazunori Ogata >> >>> Cc: "ppc-aix-port-dev at openjdk.java.net" >> dev at openjdk.java.net>, Claes Redestad , >> core- >>> libs-dev , "nio-dev at openjdk.java.net" >>> >>> Date: 2017/06/28 03:32 >>> Subject: RE: 8179527: Ineffective use of volatile hurts performance of >>> Charset.atBugLevel() >>> >>> Hi Ogata, >>> >>> I think I agree with Alan that the Charset.atBugLevel() method can >>> completely be eliminated from java/nio/charset. >>> >>> Ogata, would you respin your change to remove it and post it for review? >> I >>> can then sponsor it for you. >>> >>> @Alan: Do we need a CSR ("Compatibility & Specification Review") request >>> here since support for "sun.nio.cs.bugLevel" will be removed? >>> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>>> Sent: Dienstag, 27. Juni 2017 10:13 >>>> To: Claes Redestad ; Langer, Christoph >>>> ; Kazunori Ogata ; >>>> core-libs-dev ; >> nio-dev at openjdk.java.net >>>> Cc: ppc-aix-port-dev at openjdk.java.net >>>> Subject: Re: 8179527: Ineffective use of volatile hurts performance of >>>> Charset.atBugLevel() >>>> >>>> On 27/06/2017 08:36, Claes Redestad wrote: >>>>> The check of Charset.atBugLevel in checkName should no longer >> happen >>>>> for the majority of situations, as that test is now only done if the >>>>> charset name is "" (see >>>>> https://bugs.openjdk.java.net/browse/JDK-8174831), >>>> Kazunori's mail didn't mention the JDK build he is using, it may have >>>> been JDK 8 rather than JDK 9. >>>> >>>>> since what differs between 1.4 and 1.5 was apparently whether or not >>>>> the empty string was to be accepted as a valid Charset... >>>>> >>>>> So yes, if we can get rid of the test altogether, we'll be even >> better >>>>> off! >>>> JDK-4786884 is the original issue. If there was any code dependent on >>>> the broken behavior in 1.4 then I would expect it should have been >> fixed >>>> by now. So I think it can be removed. >>>> >>>> -Alan From Alan.Bateman at oracle.com Wed Jun 28 09:00:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Jun 2017 10:00:06 +0100 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <9a235816b1544dd587a1e6d2268e6407@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> Message-ID: <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> On 27/06/2017 19:32, Langer, Christoph wrote: > : > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request here since support for "sun.nio.cs.bugLevel" will be removed? > This system property pre-dates OpenJDK but it would have had a CCC at the time. So creating a CSR to indicate that it can no longer be used to get to JDK 1.4 behavior would be good. Thanks. -Alan From christoph.langer at sap.com Wed Jun 28 09:23:43 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Jun 2017 09:23:43 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> Message-ID: Hi, I just filed the CSR: https://bugs.openjdk.java.net/browse/JDK-8183116. I set it to status "Proposed". I assume it will be handled by the csr group automatically? As for the patch: I just recognized that we'll need to update the tests jdk/test/java/nio/charset/Charset/EmptyCharsetName.java and jdk/test/java/nio/charset/CharsetDecoder/AverageMax.java if we remove "sun.nio.cs.bugLevel". E.g. remove the second run with -Dsun.nio.cs.bugLevel=1.4 and clean the code for that. @Ogata: Can you please do that? You might chose to wait until the CSR process is done... Best regards Christoph PS: The bug is https://bugs.openjdk.java.net/browse/JDK-8182743, not 8179527, as the Subject indicates. > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Mittwoch, 28. Juni 2017 11:00 > To: Langer, Christoph ; Kazunori Ogata > > Cc: ppc-aix-port-dev at openjdk.java.net; Claes Redestad > ; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > > > On 27/06/2017 19:32, Langer, Christoph wrote: > > : > > > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > here since support for "sun.nio.cs.bugLevel" will be removed? > > > This system property pre-dates OpenJDK but it would have had a CCC at > the time. So creating a CSR to indicate that it can no longer be used to > get to JDK 1.4 behavior would be good. Thanks. > > -Alan From OGATAK at jp.ibm.com Wed Jun 28 09:27:29 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 28 Jun 2017 18:27:29 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <38ffe8c4e4b44dd9994d743f17985667@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <38ffe8c4e4b44dd9994d743f17985667@sap.com> Message-ID: Hi Christoph, Thank you for helping me on the CSR. Hi Peter, Thank you for pointing out the CSR process. I've learnt. Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 17:47:41: > From: "Langer, Christoph" > To: Peter Levart , Kazunori Ogata > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, core-libs-dev , > "nio-dev at openjdk.java.net" > Date: 2017/06/28 17:47 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Petar, > > thanks for pointing out the need for the CSR, I thought so too. > > I?ll run through the CSR process? It?ll probably be an interesting > learning experience for me as well J > > Best regards > Christoph > > From: Peter Levart [mailto:peter.levart at gmail.com] > Sent: Mittwoch, 28. Juni 2017 10:45 > To: Kazunori Ogata ; Langer, Christoph > Cc: ppc-aix-port-dev at openjdk.java.net; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Ogata, > > The change looks good. > > But I think this needs to go through CSR. The CSR FAQ page at: > > https://wiki.openjdk.java.net/display/csr/CSR+FAQs > > writes... > > Q: What sort of changes require CSR review? > A: Any change to a JDK interface meant to be used outside of the JDK > itself requires CSR review. In this context "interface" isn't limited to > the Java programing language definition of an interface, but encompasses > the broader concept of a protocol between the JDK and users of the JDK. > Examples of interfaces by this definition include: > > ... > Changing or defining a new system or security property > > > The FAQ also writes: > > Q: How do I create a CSR ? > A: Do not directly create a CSR from the Create Menu. JIRA will let you do > this right up until the moment you try to save it and find your typing was in vain. > Instead you should go to the target bug, select "More", and from the drop > down menu select "Create CSR". This is required to properly associate the > CSR with the main bug, just as is done for backports. > > Since Christoph has already volunteered to be your sponsor, you could ask > him to file the CSR for you. Or I can volunteer to file it (and learn how > this goes) if Christoph doesn't have the time. It's Christophs call... > > Regards, Peter > On 06/28/2017 08:20 AM, Kazunori Ogata wrote: > Hi Christoph, > > Thank you for your suggestions and offering to sponsor my changes. > > Here is the updated webrev that removes the atBugLevel() definition in > Charset.java and its call sites in Charset.java and > Charset-X-Coder.java.template. Please review this: > > http://cr.openjdk.java.net/~horii/8179527/webrev.01/ > > > Regards, > Ogata > > > "Langer, Christoph" wrote on 2017/06/28 > 03:32:51: > > From: "Langer, Christoph" > To: Alan Bateman , Kazunori Ogata > > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, Claes Redestad , core- > libs-dev , "nio-dev at openjdk.java.net" > > Date: 2017/06/28 03:32 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Ogata, > > I think I agree with Alan that the Charset.atBugLevel() method can > completely be eliminated from java/nio/charset. > > Ogata, would you respin your change to remove it and post it for review? > I > can then sponsor it for you. > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > > here since support for "sun.nio.cs.bugLevel" will be removed? > > Best regards > Christoph > > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Dienstag, 27. Juni 2017 10:13 > To: Claes Redestad ; Langer, Christoph > ; Kazunori Ogata ; > core-libs-dev ; > nio-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > On 27/06/2017 08:36, Claes Redestad wrote: > > The check of Charset.atBugLevel in checkName should no longer happen > for the majority of situations, as that test is now only done if the > charset name is "" (see > https://bugs.openjdk.java.net/browse/JDK-8174831), > Kazunori's mail didn't mention the JDK build he is using, it may have > been JDK 8 rather than JDK 9. > > since what differs between 1.4 and 1.5 was apparently whether or not > the empty string was to be accepted as a valid Charset... > > So yes, if we can get rid of the test altogether, we'll be even > better > off! > JDK-4786884 is the original issue. If there was any code dependent on > the broken behavior in 1.4 then I would expect it should have been > fixed > by now. So I think it can be removed. > > -Alan > > > From christoph.langer at sap.com Wed Jun 28 09:41:04 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Jun 2017 09:41:04 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <587313ab0dcf483abb3eb300bc779695@sap.com> Message-ID: Hi Claes, this looks like a good idea, too. I'll try to take care of it after the Charset.atBugLevel() is done. Best regards Christoph > -----Original Message----- > From: Claes Redestad [mailto:claes.redestad at oracle.com] > Sent: Mittwoch, 28. Juni 2017 10:58 > To: Langer, Christoph ; Kazunori Ogata > > Cc: Alan Bateman ; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Looks good to me, pending CSR approval. > > Additionally, maybe this is a good opportunity to re-examine the very > similarly implemented sun.nio.ch.bugLevel used in sun.nio.ch.Util and > sun.nio.ch.SelectorImpl? > > As a separate bug, of course. > > /Claes > From OGATAK at jp.ibm.com Wed Jun 28 09:59:09 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 28 Jun 2017 18:59:09 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> Message-ID: Hi Christoph, Thank you for your help. I'll change the tests and update weberv. > remove the second run with -Dsun.nio.cs.bugLevel=1.4 How can I do this? Is it sufficient to remove the following line at the beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" > PS: The bug is https://bugs.openjdk.java.net/browse/JDK-8182743, not > 8179527, as the Subject indicates. Oops, I'm sorry. It was the number that my colleague opened before... Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 18:23:43: > From: "Langer, Christoph" > To: Alan Bateman , Kazunori Ogata > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, Claes Redestad , core- > libs-dev , "nio-dev at openjdk.java.net" > > Date: 2017/06/28 18:24 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi, > > I just filed the CSR: https://bugs.openjdk.java.net/browse/JDK-8183116. I > set it to status "Proposed". I assume it will be handled by the csr group > automatically? > > As for the patch: I just recognized that we'll need to update the tests > jdk/test/java/nio/charset/Charset/EmptyCharsetName.java and jdk/test/java/ > nio/charset/CharsetDecoder/AverageMax.java if we remove > "sun.nio.cs.bugLevel". E.g. remove the second run with - > Dsun.nio.cs.bugLevel=1.4 and clean the code for that. @Ogata: Can you > please do that? You might chose to wait until the CSR process is done... > > Best regards > Christoph > > PS: The bug is https://bugs.openjdk.java.net/browse/JDK-8182743, not > 8179527, as the Subject indicates. > > > > -----Original Message----- > > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > > Sent: Mittwoch, 28. Juni 2017 11:00 > > To: Langer, Christoph ; Kazunori Ogata > > > > Cc: ppc-aix-port-dev at openjdk.java.net; Claes Redestad > > ; core-libs-dev > dev at openjdk.java.net>; nio-dev at openjdk.java.net > > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > > > > > On 27/06/2017 19:32, Langer, Christoph wrote: > > > : > > > > > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > > here since support for "sun.nio.cs.bugLevel" will be removed? > > > > > This system property pre-dates OpenJDK but it would have had a CCC at > > the time. So creating a CSR to indicate that it can no longer be used to > > get to JDK 1.4 behavior would be good. Thanks. > > > > -Alan From christoph.langer at sap.com Wed Jun 28 12:04:36 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Jun 2017 12:04:36 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> Message-ID: <254e340e1a084a57bd77c1a99884ce1b@sap.com> Hi Ogata, > > remove the second run with -Dsun.nio.cs.bugLevel=1.4 > > How can I do this? Is it sufficient to remove the following line at the > beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 > EmptyCharsetName" Yes, this line should be removed. Currently there are two @run directives which cause running the testcase twice. Once in normal mode and once with bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed then the second iteration of the test is obsolete. And then one should probably remove the whole "compat" handling in the test. Best regards Christoph From david.lloyd at redhat.com Wed Jun 28 13:37:42 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 28 Jun 2017 08:37:42 -0500 Subject: Bug in sun.nio.ch.SolarisEventPort#port_dissociate In-Reply-To: <50af276f-d936-b02a-8a3b-cd5ee9b36814@redhat.com> References: <2948b87d-e8c7-71ac-eebc-ea47bfc55992@oracle.com> <89cd5b30-0733-727b-6723-605c4c80ae1d@redhat.com> <50af276f-d936-b02a-8a3b-cd5ee9b36814@redhat.com> Message-ID: <0e6a6032-1773-87ce-862c-e4b838ce8db4@redhat.com> On 06/16/2017 10:59 AM, David M. Lloyd wrote: > On 06/16/2017 10:36 AM, Alan Bateman wrote: >> On 14/06/2017 15:32, David M. Lloyd wrote: >>> >>> It's coming from a user so my information is limited but I can >>> establish that it is happening under load, and I think it corresponds >>> to an open socket being abruptly closed in another thread. >>> >>> I am not sure whether I can get it down to a test case though. I'll >>> see if I can get access to a Solaris system for testing. >>> >> If you get some idea on the conditions when this occurs then it would >> be useful. To make sure there is nothing obvious, I ran JDK tests on >> Solaris 11.3 system with the port Selector as the default. > > I'll see if I can find out more. I have gained access to a test > environment but I haven't been able to reproduce it in isolation either. We're reproducing the bug locally now, though the test is not yet standalone. I'm going to try to create a new standalone test with a large number of threads, as this seems to be a possible factor. >> All the tests pass. I can't think of a scenario where port_dissociate >> could fail with EBADF. > > It's not EBADF but EBADFD, if that makes a difference. I've been > working off of various GC-related hypotheses but without knowing the > exact conditions that precipitate EBADFD, I'm really shooting in the > dark. One would have to examine the kernel sources to get that answer. > >> It is correct to ignore ENOENT as that occurs then the file descriptor >> registered with the port is closed by dup'ing. > > Is it possible that this operation is non-atomic in the kernel, such > that the descriptor is briefly in an intermediate state before being > replaced by the placeholder? > -- - DML From brian.burkhalter at oracle.com Wed Jun 28 14:32:25 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 28 Jun 2017 07:32:25 -0700 Subject: Bug in sun.nio.ch.SolarisEventPort#port_dissociate In-Reply-To: <0e6a6032-1773-87ce-862c-e4b838ce8db4@redhat.com> References: <2948b87d-e8c7-71ac-eebc-ea47bfc55992@oracle.com> <89cd5b30-0733-727b-6723-605c4c80ae1d@redhat.com> <50af276f-d936-b02a-8a3b-cd5ee9b36814@redhat.com> <0e6a6032-1773-87ce-862c-e4b838ce8db4@redhat.com> Message-ID: On Jun 28, 2017, at 6:37 AM, David M. Lloyd wrote: > We're reproducing the bug locally now, though the test is not yet standalone. I'm going to try to create a new standalone test with a large number of threads, as this seems to be a possible factor. That would definitely be helpful and appreciated. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jun 29 12:07:03 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 29 Jun 2017 12:07:03 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> Message-ID: <1fcbb8b261b443568be8abaf4621653c@sap.com> Hi, can somebody please review my CSR: https://bugs.openjdk.java.net/browse/JDK-8183116 ? I think there should be some button to add yourself as reviewer in the CSR bug - though I have never done such a thing myself. You'll probably know what to do :) Thanks & Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 28. Juni 2017 11:24 > To: 'Alan Bateman' ; Kazunori Ogata > > Cc: ppc-aix-port-dev at openjdk.java.net; Claes Redestad > ; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi, > > I just filed the CSR: https://bugs.openjdk.java.net/browse/JDK-8183116. I set > it to status "Proposed". I assume it will be handled by the csr group > automatically? > > Best regards > Christoph > From Alan.Bateman at oracle.com Thu Jun 29 13:48:47 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Jun 2017 14:48:47 +0100 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <1fcbb8b261b443568be8abaf4621653c@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <1fcbb8b261b443568be8abaf4621653c@sap.com> Message-ID: On 29/06/2017 13:07, Langer, Christoph wrote: > Hi, > > can somebody please review my CSR: https://bugs.openjdk.java.net/browse/JDK-8183116 ? > > I think there should be some button to add yourself as reviewer in the CSR bug - though I have never done such a thing myself. You'll probably know what to do :) > A few things that could be fixed up before finalizing: 1. Link to both JDK-4853350 and JDK-4786884 as background. 2. The CSR is for the interface change, in this case, dropping the property, so I think you can drop the patch. 3. I assume you mean "JDK 1.4" rather than "Java 1.4". -Alan From christoph.langer at sap.com Thu Jun 29 14:31:45 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 29 Jun 2017 14:31:45 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <1fcbb8b261b443568be8abaf4621653c@sap.com> Message-ID: <2462f0f26aff4ffc86707f19731e28fb@sap.com> Hi Alan, thanks, I've implemented your suggestions in the CSR. I've even renamed it to better reflect that it is about dropping property sun.nio.cs.bugLevel. Don't know if this is the right thing to do - or must the CSR title always match the Bug? I'm also not allowed to delete attachments in the bug system. So, please remove the patch attachment for me, if you like. Best regards Christoph > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Donnerstag, 29. Juni 2017 15:49 > To: Langer, Christoph ; nio- > dev at openjdk.java.net > Cc: core-libs-dev > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > On 29/06/2017 13:07, Langer, Christoph wrote: > > Hi, > > > > can somebody please review my CSR: > https://bugs.openjdk.java.net/browse/JDK-8183116 ? > > > > I think there should be some button to add yourself as reviewer in the CSR > bug - though I have never done such a thing myself. You'll probably know > what to do :) > > > A few things that could be fixed up before finalizing: > > 1. Link to both JDK-4853350 and JDK-4786884 as background. > 2. The CSR is for the interface change, in this case, dropping the > property, so I think you can drop the patch. > 3. I assume you mean "JDK 1.4" rather than "Java 1.4". > > -Alan From OGATAK at jp.ibm.com Thu Jun 29 18:49:18 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Fri, 30 Jun 2017 03:49:18 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <254e340e1a084a57bd77c1a99884ce1b@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <254e340e1a084a57bd77c1a99884ce1b@sap.com> Message-ID: Hi Christoph, I updated webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.02/ This one includes changes in tests. I removed all @run and @build directives in the tests because those after removing "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the default ones. I checked the modified tests passed. I also fixed the copyright lines. Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 21:04:36: > From: "Langer, Christoph" > To: Kazunori Ogata > Cc: Alan Bateman , Claes Redestad > , core-libs-dev dev at openjdk.java.net>, "nio-dev at openjdk.java.net" dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net> > Date: 2017/06/28 21:04 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Ogata, > > > > remove the second run with -Dsun.nio.cs.bugLevel=1.4 > > > > How can I do this? Is it sufficient to remove the following line at the > > beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 > > EmptyCharsetName" > > Yes, this line should be removed. Currently there are two @run directives > which cause running the testcase twice. Once in normal mode and once with > bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed then > the second iteration of the test is obsolete. And then one should probably > remove the whole "compat" handling in the test. > > Best regards > Christoph > From sean.coffey at oracle.com Fri Jun 30 14:57:25 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 30 Jun 2017 15:57:25 +0100 Subject: 8179527:(8182743?) Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <254e340e1a084a57bd77c1a99884ce1b@sap.com> Message-ID: Ogata, minor comments from me. * The bug ID referenced in mail/webrev links is wrong. It should be 8182743 ? * The copyright change in Charset-X-Coder.java.template is the wrong format. You can simply replace 2013 with 2017. Regards, Sean. On 29/06/17 19:49, Kazunori Ogata wrote: > Hi Christoph, > > I updated webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.02/ > > This one includes changes in tests. I removed all @run and @build > directives in the tests because those after removing "@run main/othervm > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the default > ones. I checked the modified tests passed. > > I also fixed the copyright lines. > > > Regards, > Ogata > > > "Langer, Christoph" wrote on 2017/06/28 > 21:04:36: > >> From: "Langer, Christoph" >> To: Kazunori Ogata >> Cc: Alan Bateman , Claes Redestad >> , core-libs-dev > dev at openjdk.java.net>, "nio-dev at openjdk.java.net" > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > dev at openjdk.java.net> >> Date: 2017/06/28 21:04 >> Subject: RE: 8179527: Ineffective use of volatile hurts performance of >> Charset.atBugLevel() >> >> Hi Ogata, >> >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4 >>> How can I do this? Is it sufficient to remove the following line at > the >>> beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 >>> EmptyCharsetName" >> Yes, this line should be removed. Currently there are two @run > directives >> which cause running the testcase twice. Once in normal mode and once > with >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed > then >> the second iteration of the test is obsolete. And then one should > probably >> remove the whole "compat" handling in the test. >> >> Best regards >> Christoph >> > From volker.simonis at gmail.com Fri Jun 30 16:23:55 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 30 Jun 2017 18:23:55 +0200 Subject: OpenJDK on BullFreeware In-Reply-To: References: Message-ID: Hi Tony, thanks for your interest in the OpenJDK AIX port. The AIX port has been contributed by SAP in collaboration with our colleagues from IBM. It is based on SAP's internal, commercially licensed SAP JVM which is in productive use since more than 10 years. We (from SAP) do nightly builds and tests of the OpenJDK AIX port and we're happy to help with any issues we see or which are reported by the community. But of course we can not guarantee any support - after all it's an open source project :) We've also contributed the OpenJDK linux/ppc64 port which is basically the same as the AIX port with regard to the CPU-specific code (i.e. interpreter, JIT, shared code, etc) and only differs in the OS-specific part (i.e. Linux vs. AIX). We know that the linux/ppc64 port is currently distributed by all major Linux vendors (RedHat, Ubuntu, Suse, etc) and used productively on their distributions without any major issues. Until now there hasn't been such a big interest in the AIX port (for obvious reasons :) but we would very much welcome a more widespread usage. Unfortunately, there's not much AIX-specific information available. You can get the basic bits from our project page [1] and Wiki [2]. The repositories for AIX are the current OpenJDK master repositories for jdk8u [3] and jdk9 [4]. Recently, IBM has started an effort together with the AdoptOpenJDK [5] project to establish a regular, open and freely available OpenJDK build and deliver the produced binaries. I've just invited you to their Slack channel (you should receive it by mail). Please follow that thread where we've recently discussed some build issues. One thing that may be of special interest for you is the the build currently only works with XLC and relies on some libraries from the "AIX toolbox for Linux" from IBM (i.e. for freetype). Also, we don't have RPM .spec files for building RPM until now. If you have any more questions please feel free to ask on this list and/or the Slack channel. Regards, Volker [1] http://openjdk.java.net/projects/ppc-aix-port/ [2] https://wiki.openjdk.java.net/display/PPCAIXPort [3] http://hg.openjdk.java.net/jdk8u [4] http://hg.openjdk.java.net/jdk9 [5] https://wiki.openjdk.java.net/display/Adoption/Main On Fri, Jun 30, 2017 at 9:29 AM, REIX, Tony wrote: > Hi, > > I am one of the maintainers of the BullFreeware web-site where RPMs of OpenSource packages for AIX are available (for free): http://www.bullfreeware.com . > > I'd like to know: > - what is the status of this port of OpenJDK on AIX (is it usable in production ?), > - where are the sources and the instructions for building it, and > - if there already exists a RPM .spec file for building RPMs. > > Thanks/Regards, > > Cordialement, > > Tony Reix > > Bull - ATOS > IBM Coop Architect & Technical Leader > Office : +33 (0) 4 76 29 72 67 > 1 rue de Provence - 38432 ?chirolles - France > www.atos.net From OGATAK at jp.ibm.com Fri Jun 30 18:30:49 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Sat, 1 Jul 2017 03:30:49 +0900 Subject: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <254e340e1a084a57bd77c1a99884ce1b@sap.com> Message-ID: Hi Sean, Thank you for your comments. I fixed the copyright and updated webrev: http://cr.openjdk.java.net/~horii/8182743/webrev.03/ > * The bug ID referenced in mail/webrev links is wrong. It should be > 8182743 ? Yes, they should be 8182743. I fixed both. Regards, Ogata Se?n Coffey wrote on 2017/06/30 23:57:25: > From: Se?n Coffey > To: Kazunori Ogata , "Langer, Christoph" > > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, core-libs-dev , > "nio-dev at openjdk.java.net" > Date: 2017/06/30 23:57 > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts > performance of Charset.atBugLevel() > > Ogata, > > minor comments from me. > > * The bug ID referenced in mail/webrev links is wrong. It should be > 8182743 ? > * The copyright change in Charset-X-Coder.java.template is the wrong > format. You can simply replace 2013 with 2017. > > Regards, > Sean. > > On 29/06/17 19:49, Kazunori Ogata wrote: > > Hi Christoph, > > > > I updated webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.02/ > > > > This one includes changes in tests. I removed all @run and @build > > directives in the tests because those after removing "@run main/othervm > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the default > > ones. I checked the modified tests passed. > > > > I also fixed the copyright lines. > > > > > > Regards, > > Ogata > > > > > > "Langer, Christoph" wrote on 2017/06/28 > > 21:04:36: > > > >> From: "Langer, Christoph" > >> To: Kazunori Ogata > >> Cc: Alan Bateman , Claes Redestad > >> , core-libs-dev >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > >> dev at openjdk.java.net> > >> Date: 2017/06/28 21:04 > >> Subject: RE: 8179527: Ineffective use of volatile hurts performance of > >> Charset.atBugLevel() > >> > >> Hi Ogata, > >> > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4 > >>> How can I do this? Is it sufficient to remove the following line at > > the > >>> beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 > >>> EmptyCharsetName" > >> Yes, this line should be removed. Currently there are two @run > > directives > >> which cause running the testcase twice. Once in normal mode and once > > with > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed > > then > >> the second iteration of the test is obsolete. And then one should > > probably > >> remove the whole "compat" handling in the test. > >> > >> Best regards > >> Christoph > >> > > >